Cloudflare Logpush SIEM guide
This guide helps teams select datasets, destinations, fields, dashboards, alerts, and retention patterns for Cloudflare logs.
This guide helps teams select datasets, destinations, fields, dashboards, alerts, and retention patterns for Cloudflare logs.
Topics: cloudflare, resource, cloudflare, logpush, siem, guide
Machine-readable context: /ai-index.json
Step by step
Implementation steps
- 1
Define the end-to-end pipeline goal across both halves of the problem: what Cloudflare data needs to leave the edge (delivery) and what the SIEM or observability platform must do with it (analysis) for security, performance, and incident response.
- 2
Select datasets and the matching destination together: choose HTTP, security/firewall, DNS, Gateway, and Access datasets, then decide whether each flows via R2 or S3 for retention, via a direct connector to Splunk, Sentinel, or Datadog, or both.
- 3
Configure the Logpush jobs - fields, sampling, output format, and credentials - so that what gets delivered matches what the SIEM expects to parse, avoiding a mismatch between the two stages.
- 4
Stand up parsing and field mapping at the destination so delivered records are tokenised and aligned to the platform's schema (CIM, ECS, or Sentinel tables) with correct timestamps.
- 5
Decide the split between cheap long-term retention and active monitoring - for example full logs archived in R2 or S3 and a filtered, normalised subset streamed into the SIEM for detection.
- 6
Build dashboards and detection/alert rules on top of the normalised data: firewall and WAF actions, bot score and rate-limit activity, origin errors and latency, and Zero Trust access events, tuned to baseline.
- 7
Validate the whole chain from edge to alert: confirm Logpush jobs are healthy and delivering, that records parse correctly in the SIEM, that dashboards populate, and that a test event raises the expected alert with no gaps.
- 8
Assign ownership across both stages - Logpush job health and credentials on the delivery side, parsers, retention, dashboards, and rule tuning on the analysis side - and document the pipeline for managed operations.
Risk register
Risks to control
Delivery and analysis are designed separately, so the fields and format Logpush sends don't match what the SIEM parser expects.
Design the two stages together - choose fields and output format with the destination's parser in mind and validate a real batch end-to-end.
Logpush jobs fail or fall behind and the SIEM keeps showing stale data without anyone noticing.
Monitor Logpush job health and SIEM ingest lag together so a delivery failure surfaces as a pipeline alert, not a silent gap.
Everything is streamed into the SIEM at full volume, making the pipeline expensive while most of the data is never queried.
Archive full logs cheaply in R2 or S3 and stream only a filtered, normalised subset into the SIEM for active detection.
Sampling applied on the delivery side quietly weakens detections that assume complete data on the analysis side.
Keep security datasets unsampled into the SIEM and reserve sampling for high-volume traffic used only for trends, documenting the choice.
Parsing or timezone errors at the destination put events at the wrong time and break incident timelines built on delivered logs.
Validate timestamp and timezone parsing against known events as part of pipeline acceptance, before relying on the data operationally.
No single owner spans delivery and analysis, so failures fall in the gap between the teams running Logpush and the SIEM.
Name owners for both stages and document the handoffs so job health, credentials, parsers, and rules all have a clear responsible party.
Output
Useful deliverables
- End-to-end pipeline design covering delivery (Logpush) and analysis (SIEM/observability) for security, performance, and incident response.
- Combined dataset-to-destination plan mapping each Cloudflare dataset to R2/S3 retention, a SIEM connector, or both.
- Logpush job configuration (fields, sampling, format, credentials) aligned to the destination parser.
- Parsing and field-mapping configuration normalising delivered records to the platform schema.
- Retention split documenting archived full logs versus the filtered subset streamed for detection.
- Dashboard and alert-rule set built on normalised data and tuned to baseline.
- End-to-end validation report and split ownership runbook spanning Logpush health and SIEM operations.
Keep reading
Related resources
FAQ
Frequently asked questions
Common questions teams ask when putting this resource into practice.
How is this different from the Logpush checklist and the SIEM integration guide?
Those each cover one half: the Logpush checklist is about getting logs out of Cloudflare cleanly, and the SIEM integration guide is about parsing and detecting once data has arrived. This guide joins them into one pipeline - making sure what Logpush delivers matches what the SIEM parses, and that the whole chain from edge to alert is owned and validated together.
Should all our Cloudflare logs go straight into the SIEM?
Usually not. A cost-effective pattern is to archive full logs cheaply in R2 or S3 for retention and replay, while streaming only a filtered, normalised subset - typically security and firewall events - into the SIEM for active detection. That keeps SIEM ingest cost on the data analysts actually query.
What breaks most often in a Logpush-to-SIEM pipeline?
The seam between the two stages: fields or output format that Logpush sends but the SIEM parser doesn't expect, sampling on the delivery side that weakens detections on the analysis side, and Logpush job failures that leave the SIEM showing stale data. Designing and monitoring both halves together is what prevents these.
How do we validate the whole pipeline works?
Test edge to alert. Confirm the Logpush jobs are healthy and delivering on schedule, that records parse correctly and at the right time in the SIEM, that dashboards populate, and that a known test event raises the expected alert with no gaps in between. A green Logpush toggle alone doesn't prove the pipeline works.
Can Nanosek run the pipeline end to end?
Yes. As an authorized Cloudflare partner we can design and operate both stages - Logpush job configuration, datasets, destinations, and health on the delivery side, and parsing, retention, dashboards, and detection tuning on the SIEM side - with clear ownership documented for managed operations.
Nanosek
Design logging pipelines
Nanosek can turn this resource into a practical delivery plan for your environment — with rollback planning, stakeholder alignment, and 24/7 managed operations support.