Logpush service model
Logpush sends available events to a destination; it does not store, search or backfill logs for the customer.
Delivery model
Logpush sends available events to customer-controlled storage, a SIEM or a log-management destination in automatic batches, potentially more than once per minute. Cloudflare chooses the push frequency; batch-size controls influence upload size rather than delivery latency. Logpush supplies delivery only: it does not provide customer log storage or search.
No historical backfill
Each event is offered to Logpush once when it becomes available. Cloudflare cannot backfill events generated while a job is disabled or its destination is failing, so a gap in delivery is permanent. Delivery-health monitoring is therefore part of the service design, not an optional reporting extra.
- Keep destination capacity, write permissions and credentials continuously valid.
- Alert on a missing expected batch before the lost interval becomes operationally significant.
- Do not disable a job while changing the downstream parser; stage the parser against copied data instead.
Job configuration
A job binds one scope and dataset to a destination, field selection, output format, filter and delivery state.
Scope and datasets
A zone-scoped job exports one supported zone dataset such as HTTP requests, firewall events, DNS logs, Network Error Logging reports, Page Shield events, Spectrum events, WebSocket Analytics or Zaraz events. Account datasets use an account scope and are not interchangeable with a zone job. Dataset availability depends on the contracted product and plan.
Destination ownership and credentials
Before creating a job, Cloudflare can write an ownership challenge file to the exact destination. Its token proves that the destination is writable by the customer. Destination configuration can contain access keys, signed URLs or authorization headers; treat the complete value as a secret and grant only the write and path permissions required for log delivery.
- Supported destination families include Cloudflare R2, S3 and S3-compatible storage, Google Cloud Storage, Azure, HTTPS collectors and named SIEM providers.
- Allowlist Cloudflare Logpush egress addresses when the destination restricts incoming networks.
- Changing a destination can leave in-flight uploads arriving at the previous destination for approximately 10–15 minutes.
Volume and data governance
Traffic volume, selected fields and compression determine storage cost, while the event content determines privacy and retention obligations.
Fields and output options
Select fields from the chosen dataset rather than assuming every dataset shares an HTTP request schema. Custom Log Formatting can choose field names, record delimiter, field delimiter, output type, timestamp format and optional sample rate. RFC 3339 is human-readable; Unix seconds and Unix nanoseconds suit systems that require numeric time. New fields can take approximately 10–15 minutes to appear after a job update.
- Export only fields required by a defined query, alert or retention obligation.
- Parse and validate a representative batch before enabling downstream automation.
- Use the Ray ID and event timestamps where available to correlate edge events with application evidence.
Filters, sampling and batch sizing
Filters select which records are exported from a dataset. The job sample rate accepts values greater than zero and up to one; 0.1 delivers approximately one record in ten and compounds with any sampling already represented by a dataset's SampleInterval. Maximum upload bytes, records and interval constrain batch size but do not make Cloudflare process events faster.
- Reduce maximum records when a destination cannot parse large payloads reliably.
- Increase batch size cautiously for object storage when fewer objects reduce operation cost.
- Never use sampled output as a complete security audit trail.
Delivery health, limits and recovery
A job can lose events while disabled or failing, so destination verification and delivery monitoring are part of the logging design.
Volume, privacy and retention
For HTTP request logs, Cloudflare's planning guidance estimates roughly 100–250 compressed bytes per request depending on selected fields; one million requests per day is therefore approximately 100–250 MB per day before downstream indexing overhead. Other datasets add their own volume. Logs can contain IP addresses, URLs, identifiers, headers and security decisions, so collection needs an explicit purpose, access policy, encryption, retention period and deletion process.
Delivery verification and recovery
A healthy job is demonstrated by recent destination objects or accepted collector payloads that decompress, parse and cover the expected event interval. If delivery fails, repair destination permissions, credentials, capacity or parser acceptance immediately and verify the first new batch. The missing interval cannot be recovered through Logpush; document that gap and use any independent origin or application logs that were retained.
- Monitor job enabled state and the destination's most recent accepted event time.
- Distinguish an empty dataset interval from a rejected or missing upload.
- Rotate destination credentials after suspected exposure and verify both old and new destinations during the documented transition window.