Logpush Health Dashboards

Logpush Health Dashboards give you a clear view into the performance and reliability of your Logpush jobs. You can monitor the status of log delivery, diagnose issues, and understand the volume of data being sent to your configured destinations. This helps you ensure that critical log data for security, compliance, and observability is always flowing as expected.

Configure Logpush health notifications to receive alerts when your Logpush job is disabled or experiencing errors. Early detection is critical since Logpush cannot backfill logs—once data is dropped, it is permanently lost.

Health notifications work alongside the Health Dashboard to provide both real-time alerts and historical analysis of your Logpush job performance.

1. In the Cloudflare dashboard, go to the Logpush page at either the account or domain (zone) level.
2. Go to the Health tab.
3. Select the job you want to analyze.
4. Specify the time range you want to review.
5. (Optional) From the Jobs tab, locate the job you want to analyze.
6. Hover over the Job Health (24h) column for that job and select View Health.
7. You will be redirected to the Health tab, where you can select the desired time range for analysis.

• The Health Dashboard displays up to 30 days of health metrics for each Logpush job in the Cloudflare dashboard.
• The raw health metrics can be queried via the logpushHealthAdaptiveGroups dataset in the GraphQL API.
• You can explore or test queries using the Cloudflare GraphQL Explorer ↗.

A single log entry generated by Cloudflare, such as an HTTP request, DNS query, or Access event.

A group of logs that Cloudflare uploads together to your destination as a single file or request. A batch is also referred to as a file.

A single attempt to upload a batch of logs to your destination. If the first attempt fails, Cloudflare automatically retries until the upload succeeds or the retry limit is reached. Each upload can have one of three outcomes: Successful, Retry attempts, or Failed.

Indicates that a batch of logs was uploaded to your destination without errors or timeouts. Once an upload succeeds, the batch is marked as delivered and no further retries occur.

Additional upload attempts made after an initial failure. The count includes the first failed attempt. Retries continue until the batch is successfully delivered or the buffered data ages out of the retention window.

Indicates that all upload attempts for a batch were exhausted without success. When a batch fails, Cloudflare cannot deliver its logs to your destination, and all logs in that batch are dropped. These logs are permanently lost.

The Logpush Health Dashboard provides two complementary views that help you monitor and troubleshoot log delivery: Upload Health and Upload Reliability.

Each view highlights a different aspect of job performance — what was delivered and how reliably it was delivered.

Upload Health helps you understand how much data was successfully uploaded and where uploads failed or data was dropped. This view answers: Are uploads succeeding, and are logs reaching the destination?

• Batch Upload Success vs. Failure: Displays the number of batches that were successfully uploaded versus those that failed.

  • Successful Uploads - Total number of batches successfully uploaded.
  • Failed Uploads - Total number of batches that failed to upload due to connection or destination issues.

• Log Lines Uploaded: Tracks the total number of log lines successfully uploaded to your destination.

  • Uploaded Log Lines - Total number of log lines successfully delivered.
  • Dropped Log Lines - Total number of log lines that could not be delivered after all retry attempts.

• Data Volume: Shows the total volume of log data uploaded (in bytes), both compressed and uncompressed.

  • Uncompressed Data (raw) - Total size of log data before compression.
  • Compressed Data (uploaded) - Total size of log data after compression, representing the actual bytes transmitted.

Start here to assess overall data delivery health:

• High upload success and stable data volume indicate a healthy Logpush job.
• Drops, spikes, or failed uploads suggest delivery issues — proceed to Upload Reliability to investigate root causes.

Upload Reliability helps you identify factors affecting reliability, stability, and latency across all upload attempts (including retries and failures). This view answers: Are uploads stable and efficient?

• Uploaded Logs by Status Code Shows the number of batches that were successful, failed, or retried, categorized by status code.

  • Success Rate - Percentage of batches successfully uploaded.
  • Successful Uploads - Total number of batches successfully completed.

• Upload Duration: Shows the average time taken to complete each batch upload, broken down by status code.

  • Destination Availability - How often Cloudflare successfully connected to your destination and completed uploads.
  • Average Upload Duration - Average time taken to upload logs after they are generated.

• Retry Attempts: Displays the number of retries made after failed uploads, broken down by status code.

  • Retry Attempts - Total number of upload attempts made after previous failures (includes the first failed attempt).

Use this view to troubleshoot reliability issues:

• High latency, frequent retries, or low destination availability indicate potential instability in the destination endpoint or network.
• Combine with Upload Health metrics to correlate delivery success with underlying reliability patterns.

The Logpush Health Dashboards help you monitor the status, reliability, and performance of your Logpush jobs. Use this guide to interpret each chart, identify the root cause of anomalies, and take corrective action.

When Cloudflare cannot receive an HTTP status code from your destination — for example, the connection never completes or the request is aborted — the delivery attempt is recorded with a Cloudflare-generated error code instead of an HTTP status. These codes appear in the Health Dashboard and in the logpushHealthAdaptiveGroups GraphQL dataset.

Cloudflare applies several timeouts at different layers of the upload path. Understanding each layer helps you interpret destination error codes and tune your destination endpoint.

• Ensure your endpoint acknowledges each POST within 2 minutes end-to-end, and keeps the request body flowing with no gap longer than 10 seconds between chunks.
• If you terminate connections at a load balancer or WAF, verify that idle-connection and read timeouts are not shorter than the values in the timeout table. Aggressive tuning at the receiver frequently manifests as 1106 or 1107 errors on the Cloudflare side.
• If you rely on HTTP/2, make sure your server responds to PING frames within 15 seconds.

Amazon S3, Google Cloud Storage, and Microsoft Azure destinations do not use the shared Cloudflare HTTP transport. They use client libraries that configure their own timeouts, so none of the values in the timeout table apply. Individual uploads may therefore run longer than 2 minutes before failing.

Logpush is designed to handle temporary destination issues through automatic retries. When your destination is temporarily unavailable, Cloudflare buffers the affected batches and retries them.

Retries do not stop after a fixed number of attempts. Instead, Cloudflare continues to retry a batch until either the upload succeeds and the batch is marked as delivered, or the buffered data ages out of the internal retention window. When data ages out, the batch is dropped (recorded as 1201 FlushMaxLag) and the log lines it contained are permanently lost.

If no batch has been successfully delivered for 24 hours, Cloudflare assumes the destination is permanently unavailable and disables the job. You can re-enable the job from the Cloudflare dashboard ↗ once the destination issue is resolved. Cloudflare cannot backfill logs generated while the job was disabled.

When a destination is slow but still accepting uploads, Logpush automatically increases the number of parallel uploads to catch up. Once the destination recovers and lag returns to normal, concurrency scales back down.