Skip to content
Back to Cloud Services

Cloudflare Logpush to S3/R2

Stream Cloudflare logs (HTTP requests, Workers, Firewall) to R2/S3/BigQuery for long-term analysis.

CloudflareIntermediate

Why

Logpush sends logs to your storage in near-real-time — no Logpull polling, no missed events. Essential for compliance, security forensics, and custom analytics beyond Cloudflare's dashboard.

Cloudflare's network spans 330+ cities in 125+ countries, serving 20% of all internet traffic. Workers have 0ms cold starts (isolate-based) and the free tier covers 100k requests/day.

When

Enable for compliance (PCI/SOC require log retention), security analysis, and SLA monitoring. Avoid if dashboard analytics suffice (Logpush costs per log line).

How

1. Create destination — R2 bucket or S3 bucket with write policy 2. Generate job — dashboard → Analytics & Logs → Logpush → Create 3. Select dataset — http_requests, firewall_events, workers_logs, dns_logs 4. Filter — by status code, zone, hostname to reduce volume/cost 5. Format — JSON or CSV, with optional gzip compression 6. Frequency — every 60s or 5min batches 7. Verify — check destination for .log files, query with Athena/BigQuery

Example

# Create Logpush job to R2 via API curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/logpush/jobs" -H "Authorization: Bearer {token}" -d '{ "name": "http-requests-to-r2", "destination_conf": "r2://my-logs/{DATE}?region=auto", "dataset": "http_requests", "output_options": { "field_names": ["ClientIP","ClientRequestURI","EdgeResponseStatus","OriginResponseTime"], "format": "json" }, "frequency": "60s" }' # Query logs in BigQuery after sync SELECT ClientRequestURI, COUNT(*) AS hits, AVG(OriginResponseTime) AS avg_ms FROM cloudflare_logs.http_requests WHERE DATE(timestamp) = '2026-01-15' GROUP BY ClientRequestURI ORDER BY hits DESC LIMIT 20;

Common Problems

  • ⚠Cost surprises — log every request = huge volume, filter to error/4xx/5xx first
  • ⚠Destination permissions — R2/S3 needs specific write policy, Logpush fails silently
  • ⚠Schema changes — Cloudflare may add fields, break strict parsers, use flexible JSON

Best Practices

  • ✓Filter aggressively — only push 4xx/5xx or slow requests, cut volume 95%
  • ✓Use R2 not S3 — zero egress, query from Workers/BigQuery without transfer fees
  • ✓Partition by date — {DATE} in path enables efficient time-range queries

FAQ

What is Cloudflare Logpush to S3/R2 and what problem does it solve?

Stream Cloudflare logs (HTTP requests, Workers, Firewall) to R2/S3/BigQuery for long-term analysis. It lets developers deploy, store, and scale without self-managing infrastructure — a core reference for cloud service selection.

How do I get started with Cloudflare Logpush to S3/R2 in 5 minutes?

Two steps to run it: (1) Create destination — R2 bucket or S3 bucket with write policy; (2) Generate job — dashboard → Analytics & Logs → Logpush → Create. Validate on the free tier first, then wire into production.

What is the #1 pitfall with Cloudflare Logpush to S3/R2?

The most frequent issue is: Cost surprises — log every request = huge volume, filter to error/4xx/5xx first. Run a pre-launch checklist item by item, and add policy/config scanning in CI.

What are the best practices for Cloudflare Logpush to S3/R2?

Best practices for Cloudflare Logpush to S3/R2 include: Filter aggressively — only push 4xx/5xx or slow requests, cut volume 95%; Use R2 not S3 — zero egress, query from Workers/BigQuery without transfer fees; Partition by date — {DATE} in path enables efficient time-range queries. The first one — "Filter aggressively — only push 4xx/5xx or slow requests, cut volume 95%" — should be a team default baked into your IaC templates.

How do I control cost and avoid bill surprises with Cloudflare Logpush to S3/R2?

Three ways to prevent overspend: (1) tag every resource with env/team and enable billing alarms; (2) set budget thresholds to trigger Slack/email alerts; (3) review idle resources in Cost Explorer regularly and clean them up. Most Cloudflare Logpush to S3/R2 options offer a free tier — validate within free quota before scaling.