Cloudflare Opens Packet-Level Logging to SIEMs and Monitoring Stacks
Cloudflare has introduced Network Analytics Logs, a new dataset for Enterprise customers of Magic Transit, Magic Firewall, Magic WAN, and Spectrum. With this feature, teams can stream packet samples from Cloudflare's network-layer protections directly to HTTP endpoints, storage services like R2, network monitoring tools such as Kentik, or SIEM platforms like Splunk for near real-time traffic analysis and DDoS investigation.
Log Contents and Sampling Model
Logs are pushed continuously in JSON format and contain packet samples for traffic that was either dropped or passed by three mitigation layers:
- Network-layer DDoS Protection Ruleset
- Advanced TCP Protection
- Magic Firewall
Not every mitigation applies to every Cloudflare service. The table below maps each service to the applicable mitigation systems.
Mitigation System |
Cloudflare Service | ||
|---|---|---|---|
| Magic Transit | Magic WAN | Spectrum | |
| Network-layer DDoS Protection Ruleset | ✅ | ❌ | ✅ |
| Advanced TCP Protection | ✅ | ❌ | ❌ |
| Magic Firewall | ✅ | ✅ | ❌ |
Because Cloudflare processes packets through these systems in the order listed above, a single packet that clears all three layers can generate up to three separate log entries. This is useful when tracing the path of a packet across the stack. For Magic Transit users, however, only the passed packets recorded by the last system (Magic Firewall) should be counted to avoid inflating total traffic figures.
An example log entry:
{"AttackCampaignID":"","AttackID":"","ColoName":"bkk06","Datetime":1652295571783000000,"DestinationASN":13335,"Direction":"ingress","IPDestinationAddress":"(redacted)","IPDestinationSubnet":"/24","IPProtocol":17,"IPSourceAddress":"(redacted)","IPSourceSubnet":"/24","MitigationReason":"","MitigationScope":"","MitigationSystem":"magic-firewall","Outcome":"pass","ProtocolState":"","RuleID":"(redacted)","RulesetID":"(redacted)","RulesetOverrideID":"","SampleInterval":100,"SourceASN":38794,"Verdict":"drop"}
The complete field reference is documented in the Cloudflare developers portal: Network Analytics Logs fields.
Enabling Logpush with a Splunk HEC
Network Analytics Logs are currently available only via API. The setup has three stages: create a Cloudflare API token, obtain a Splunk HTTP Event Collector (HEC) token, and create and enable the Logpush job.
Creating the Cloudflare API Token
In the Cloudflare dashboard, navigate to My Profile then API Tokens. Create a custom token with an Account-scoped permission that can edit Logs, optionally restricting it to a subset of accounts. Finish by copying the generated token; no email address is required when authenticating with an API token.

Reported problems often warrant a look at the token creation documentation in Cloudflare's developers site.
Creating a Splunk HEC Token
Splunk Cloud trial accounts work for this flow, though any service that accepts HTTPS logs is a suitable destination. For on-premise SIEM appliances, make sure to allow Cloudflare IP ranges through your firewall.
Inside Splunk, navigate to Settings > Data Input, create a new HTTP Event Collector input, and save both the HEC token and the allocated Splunk hostname for the next step.

Creating the Logpush Job
A single API call creates and enables the job. A tool like Postman works well for this, but any API client or script will do. Network Analytics Logs are scoped to the account rather than to a zone, so the endpoint differs from datasets like HTTP requests or DNS logs:
https://api.cloudflare.com/client/v4/accounts/{account-id}/logpush/jobs
The {account-id} is the 32-character string at the end of your Cloudflare dashboard URL. Build the request as follows:

The request body must include the destination configuration (destination_conf) and identify the dataset as network_analytics_logs. For Splunk Cloud, the destination configuration has this format:
splunk://{your-splunk-hostname}.splunkcloud.com:8088/services/collector/raw?channel={channel-id}&header_Authorization=Splunk%20{your-splunk–hec-token}&insecure-skip-verify=false
Here, {your-splunk-hostname} is the hostname assigned by Splunk Cloud, {channel-id} is any unique identifier you assign, and {your-splunk–hec-token} is the HEC token generated earlier. Also ensure that your Splunk instance has a valid SSL/TLS certificate so the connection remains encrypted.
To confirm the job was created, send a GET request to the same URL. The response should resemble the following:
{
"errors": [],
"messages": [],
"result": {
"id": {job-id},
"dataset": "network_analytics_logs",
"frequency": "high",
"kind": "",
"enabled": true,
"name": null,
"logpull_options": null,
"destination_conf": "{your-unique-splunk-configuration}",
"last_complete": null,
"last_error": null,
"error_message": null
},
"success": true
}
After the job is active, packet samples should begin arriving at your Splunk HEC shortly. A sample response confirming job status:
{
"destination_conf": "{your-unique-splunk-configuration}",
"dataset": "network_analytics_logs",
"token": "{your-splunk-hec-tag}",
"enabled": "true"
}
Additional Logpush API examples are available in the Cloudflare developers documentation.

Using R2 to Offset Log Costs
Third-party cloud storage fees can escalate with heavy log volume, putting budgets against visibility needs. Cloudflare's R2 offers a lower-cost option: store Network Analytics Logs in R2 instead of a third-party destination. Details on R2 features and pricing, along with information on enabling the integration, are available on the Cloudflare blog; contact your account team to turn on R2.
A New Dataset in the Logpush Family
Network Analytics Logs are the latest addition to Cloudflare's Logpush family for Enterprise customers, joining DNS logs, Firewall events, HTTP requests, NEL reports, Spectrum events, Audit logs, Gateway DNS, Gateway HTTP, and Gateway Network logs. These datasets give operators a more complete view when layered with their own server, firewall, router, and appliance logs for troubleshooting, tuning, and reporting.



