Cloudflare Logpush Jobs Silently Failing: Detecting the Gaps Before Your SIEM Has a Blind Spot

Cause 1: Destination write permission revoked. The most common cause: after a Logpush job is created, the destination S3 bucket policy, Azure Blob SAS token, or Splunk HEC token is changed. Cloudflare attempts delivery, receives a permission error (HTTP 403 or equivalent), and stops retrying. The job stays enabled but no longer delivers.

Cause 2: Destination credential rotation. If the IAM access key (for S3), service principal (for Azure Blob), or API token (for Datadog, Splunk) used by the Logpush job is rotated without updating the job's configuration, all subsequent delivery attempts fail silently.

Cause 3: Destination quota or storage limit reached. An S3 bucket or Azure Blob container that hits its quota, an account that hits its Splunk storage limit, or a Datadog account that hits its log ingestion limit may respond to Logpush delivery attempts with errors. Cloudflare stops delivering without alerting.

Cause 4: Field format incompatibility after a Cloudflare log schema change. Cloudflare occasionally adds new fields or changes log field names across schema versions. Destinations that enforce strict schema validation (like a Splunk index with a fixed field list) may reject batches containing new unknown fields. Delivery fails while the Cloudflare dashboard shows the job as enabled.

Cause 5: Zone or account change that orphans the job. Moving a domain to a different Cloudflare account, changing the zone's plan, or deleting a Cloudflare Access application that was the trigger for logs can orphan an existing Logpush job. The job appears enabled but has no valid log source to pull from.

Method 1: Poll the Logpush API for last_complete timestamp.

Cloudflare's Logpush API returns job metadata including the last successful delivery timestamp. Query it regularly:

curl -X GET \
  "https://api.cloudflare.com/client/v4/zones/<zone-id>/logpush/jobs" \
  -H "Authorization: Bearer <api-token>" \
  -H "Content-Type: application/json"

The response includes each job's last_complete field. Set up a monitoring script that alerts if last_complete is more than 2x the job's frequency setting behind the current time.

Method 2: Monitor for log volume anomalies in the SIEM.

Set up a SIEM detection rule that alerts when the volume of Cloudflare log events drops below a threshold that is statistically anomalous for the time of day. Even a rough threshold (fewer than 10 events in a 15-minute window during business hours) catches complete delivery stoppages. This is simpler than it sounds: Cloudflare WAF and DNS produce high-volume, consistent log streams that make volume anomalies easy to detect.

Method 3: Enable Cloudflare Logpush alerts.

Cloudflare's dashboard (Notifications > Create Notification) includes a 'Logpush Health Alert' notification type. This notification fires when a Logpush job has not successfully delivered in a configured interval. Enable this alert and route it to your alerting channel. It is not enabled by default.

Step 1: Check the job's error field.

The Logpush API job metadata includes an error_message field when delivery has failed:

curl -X GET \
  "https://api.cloudflare.com/client/v4/zones/<zone-id>/logpush/jobs/<job-id>" \
  -H "Authorization: Bearer <api-token>"

An error message like AccessDenied or NoSuchBucket for S3 destinations points directly to the destination permission issue.

Step 2: Validate destination write access manually.

For S3: attempt a test write from a machine that uses the same IAM credentials Cloudflare is using:

aws s3 cp /dev/null s3://<bucket>/<prefix>/test.txt --sse AES256

If this fails with AccessDenied, the bucket policy or IAM permission is the issue.

For Splunk: test the HEC token with a manual push:

curl -k https://<splunk-host>:8088/services/collector \
  -H 'Authorization: Splunk <HEC-token>' \
  -d '{"event":"test"}'

Step 3: Check for schema changes at the destination.

If write access is confirmed but delivery is still failing, check whether your destination enforces schema validation. For Splunk, review the index's field extraction configuration for new Cloudflare fields that may be triggering parsing errors.

Fix: Restore destination write permissions.

For S3: re-attach the Cloudflare Logpush bucket policy. The required policy is documented in Cloudflare's docs and includes s3:PutObject on the destination prefix. After updating the policy, re-verify the job by triggering a test delivery:

curl -X POST \
  "https://api.cloudflare.com/client/v4/zones/<zone-id>/logpush/jobs/<job-id>/check" \
  -H "Authorization: Bearer <api-token>"

Fix: Update rotated credentials.

Delete the existing Logpush job and recreate it with the new credentials. Logpush jobs store credentials at creation time and there is no in-place credential update path in the current API. Recreating the job requires re-running the ownership verification step, which writes a probe file to the destination.

Backfilling the gap using Cloudflare Logs Received API.

For events during the gap period, use the Cloudflare HTTP pull API to retrieve specific time ranges:

curl -X GET \
  "https://api.cloudflare.com/client/v4/zones/<zone-id>/logs/received?start=<unix-start>&end=<unix-end>&fields=RayID,ClientIP,EdgeResponseStatus" \
  -H "Authorization: Bearer <api-token>"

The maximum lookback is 7 days. Events older than 7 days cannot be retrieved via the pull API even if Logpush delivery was failing during that period.

Logs delayed but not lost: batch delivery timing. Logpush delivers in batches, not in real time. The batch frequency is configurable (every 5 minutes to every 24 hours). A detection engineer expecting near-real-time logs may interpret the normal batch delay as a failure. Confirm the job's configured frequency matches your detection latency requirements.

High cardinality destinations filling up fast. Cloudflare WAF logs for high-traffic zones produce millions of events per day. An S3 bucket lifecycle policy that was set during low-traffic testing may no longer clear old logs fast enough, causing the bucket to hit a size limit that triggers put failures. Review bucket lifecycle and retention policies after any significant traffic increase.

Zone deletion removes the Logpush job. If a Cloudflare zone is deleted, its associated Logpush jobs are also deleted and do not automatically transfer to another zone or account. After zone migration or account restructuring, audit the Logpush jobs in the destination account to confirm coverage has not changed.

To prevent silent Logpush failures from recurring:

1. Enable the Cloudflare 'Logpush Health Alert' notification for every production job.
2. Add a SIEM alert on Cloudflare log volume drops (fewer events than your 10th percentile baseline for a 30-minute window during business hours).
3. Set a calendar reminder to rotate Logpush-related credentials on a schedule and update the Logpush job at the same time -- not separately.
4. Add the Logpush job ID and destination configuration to your credential rotation runbook so it is not omitted during key rotations.
5. Poll the Logpush API's last_complete field from a cron job and push the value as a custom metric to your monitoring platform.