Cloudflare Logpush checklist
Use this checklist to design Cloudflare Logpush before relying on logs for operations or incident response. It covers visibility goals, datasets, fields, destination credentials, parsing, normalization, retention, alerting, dashboards, reporting, and managed operations handover.
Use this checklist to design Cloudflare Logpush before relying on logs for operations or incident response. It covers visibility goals, datasets, fields, destination credentials, parsing, normalization, retention, alerting, dashboards, reporting, and managed operations handover.
Topics: cloudflare, resource, cloudflare, logpush, checklist
Machine-readable context: /ai-index.json
Step by step
Step-by-step checklist
- 1
Define the visibility goal first - security investigation, performance analysis, compliance retention, or billing/usage - because that determines which datasets and fields you actually need rather than exporting everything.
- 2
Select the Logpush datasets that match the goal: HTTP requests, Firewall/security events, DNS logs, Gateway and Access logs for Zero Trust, Spectrum events, NEL reports, or Workers Trace events, enabling only what you will use.
- 3
Choose the destination and confirm its credentials and write access: R2, AWS S3, Google Cloud Storage, Azure, or a direct connector to Splunk, Microsoft Sentinel, Datadog, or an HTTP endpoint - including bucket/path layout and ownership.
- 4
Pick the fields per dataset deliberately - keep the ones you will query (timestamps, client IP, host, path, status, ray ID, action, rule ID, bot score) and drop noise - and decide whether to redact sensitive fields.
- 5
Decide on sampling: full logs for security and compliance, or a sample rate for high-volume HTTP traffic where a subset is enough for trend analysis, and record the rate so consumers know what they are seeing.
- 6
Set the output format and timing options the destination expects - log type, timestamp format, batching, and (for object storage) the filename and folder convention that downstream tooling will parse.
- 7
Validate end-to-end before relying on it: confirm jobs are enabled and healthy, batches are arriving on schedule, records are well-formed, and there are no gaps - then check failure handling and retention on the destination.
- 8
Assign ownership and operations: who watches for failed pushes, who manages destination credentials and lifecycle/retention policies, and how the configuration is documented for handover to managed operations.
Risk register
Risks to control
Every dataset and field is enabled 'just in case', driving up destination storage and query cost while burying the signal.
Drive dataset and field selection from a stated visibility goal and keep only the fields you will actually query.
Destination credentials or bucket permissions are wrong, so Logpush jobs silently fail and logs are missing when needed.
Verify write access and run a delivery test per destination, then monitor job health so failures are caught immediately, not during an incident.
A sample rate is applied to security or compliance logs, leaving gaps in exactly the data an investigation or auditor needs.
Use full logs for security and compliance datasets and reserve sampling for high-volume traffic used only for trends, recording the rate explicitly.
Sensitive fields are exported to a third-party destination without redaction, creating a privacy or compliance exposure.
Review field-level content, redact or omit personal and secret data, and confirm the destination's retention and access controls meet policy.
The filename, folder, or timestamp convention doesn't match what downstream parsing expects, so logs land but can't be ingested.
Agree the output format, path layout, and timestamp format with the destination owner before enabling the job and validate a real batch.
No one owns the pipeline, so failed pushes, expired credentials, and retention drift go unnoticed.
Assign a named owner for job health, credential rotation, and lifecycle/retention policy, and document the configuration for handover.
Output
Useful deliverables
- Visibility-goal statement linking each enabled dataset to a security, performance, compliance, or billing purpose.
- Dataset and field selection map per zone or account, including redaction decisions.
- Destination configuration record covering R2/S3/GCS/Azure or SIEM connector, credentials, and bucket/path layout.
- Sampling policy stating which datasets are full and which are sampled, with the rate.
- Output-format specification (log type, timestamp format, batching, filename convention) agreed with the destination owner.
- End-to-end validation report confirming job health, batch delivery, record integrity, and absence of gaps.
- Ownership and operations sheet for job monitoring, credential rotation, retention, and managed-operations handover.
Keep reading
Related resources
FAQ
Frequently asked questions
Common questions teams ask when putting this resource into practice.
Which Logpush datasets should I actually enable?
Only the ones tied to a stated goal. Security work usually needs Firewall/security events and HTTP requests; Zero Trust needs Gateway and Access logs; DNS visibility needs DNS logs. Enabling datasets you won't query just adds cost and noise, so start from what you intend to investigate or report on.
Can I send Logpush to my own bucket and to a SIEM at the same time?
Yes. Logpush supports object-storage destinations like R2, S3, GCS, and Azure as well as direct connectors to platforms such as Splunk, Sentinel, and Datadog, and you can run multiple jobs. A common pattern is cheap long-term retention in R2 or S3 plus a filtered stream into the SIEM for active monitoring.
Should I sample logs or keep them complete?
Keep security and compliance datasets complete - sampling there leaves gaps an investigation or audit will need. Sampling is reasonable only for very high-volume HTTP traffic used for trend analysis, and you should record the sample rate so anyone reading the data knows it isn't the full picture.
How do I know Logpush is actually delivering?
Don't assume it from a green toggle. Validate end-to-end: confirm the job is enabled and healthy, that batches arrive on the expected schedule, that records are well-formed in the destination, and that there are no time gaps. Then set up monitoring so a failed push is noticed immediately.
How is this checklist different from a SIEM integration guide?
This checklist is about getting Cloudflare logs out cleanly - datasets, fields, destination, sampling, format, and ownership. SIEM integration picks up at the destination: parsing those logs, mapping them to a schema, building dashboards, and writing detection rules. Logpush is delivery; SIEM integration is what you do with the data once it lands.
Nanosek
Plan Logpush
Nanosek can turn this resource into a practical delivery plan for your environment — with rollback planning, stakeholder alignment, and 24/7 managed operations support.