Cloudflare Logpull Explained: Retention, Limits, and Why It's Now Legacy
Logpull is Cloudflare’s original way to get raw HTTP request logs: you call a REST API and download the logs for a time range.
It still works. But before you build on it, you need to know three things: who can use it, how far back it goes, and why Cloudflare is steering people away from it.
Who can use Logpull?
Only Enterprise customers. Cloudflare’s docs are direct: “Logpull is available to customers on the Enterprise plan.”
On Free, Pro, and Business plans, there are no raw request logs to pull. You get aggregated analytics through the dashboard and the GraphQL API instead. See how long Cloudflare keeps analytics data for what those plans do get.
How long does Logpull keep logs?
From Cloudflare’s documentation:
You can query for logs starting from 1 minute in the past and go back at least 3 days and up to 7 days.
Log retention also has to be turned on for the zone. If it isn’t enabled, there’s nothing to pull.
So even on Enterprise, Logpull is a short rolling buffer, not an archive. Anything older than the window is gone. Cloudflare’s FAQ puts it plainly: “If you need your logs for a longer time period, download and store them locally.” Or, from the same docs: “For longer durations, we recommend using Logpush.”
Received time vs. request time
This detail trips up almost everyone who builds on Logpull.
The endpoint is logs/received, and the time range you ask for is when Cloudflare received and processed the logs, not when the requests happened. There’s a delay between a request hitting the edge and its log being written to disk.
So if you ask for 16:10–16:13, you’ll see requests with timestamps from before 16:10. That’s expected. The actual request time is in each log line:
EdgeStartTimestamp— when the edge started processing the requestEdgeEndTimestamp— when it finished
Cloudflare designed it this way on purpose. If you query continuous, back-to-back windows of received time, you get every log exactly once, with no late arrivals and no duplicate calls.
What that means for your polling job:
- Never leave gaps between windows. Each call’s start should be the previous call’s end.
- Don’t re-query “the last 5 minutes” by request time. You’ll miss late-arriving logs.
- Group or partition by
EdgeStartTimestampafter download, not by the window you requested, if you want your archive organized by when traffic actually happened.
Logpull is now a legacy feature
Cloudflare describes Logpull as “a legacy feature” and recommends Logpush or Logs Engine instead.
The difference:
| Logpull | Logpush | |
|---|---|---|
| Model | You request logs | Cloudflare sends logs to you |
| History | 3–7 day buffer | Whatever your destination keeps |
| Your job | Poll reliably, never miss a window | Run and pay for the destination |
| Status | Legacy | Recommended |
The hidden problem: gaps
If you build an archive on Logpull, your history is only as good as your polling job.
Because the windows have to be continuous, every missed call is a hole you have to backfill. If your cron job fails for longer than the retention window (a broken deploy, an expired token, a paused server), those logs are gone. Nothing tells you until you need them.
That’s why most teams that start with Logpull end up on Logpush, and then find themselves running a storage and query stack. We break down those costs in Logpush vs. Logpull: the hidden infrastructure costs.
What if you’re not on Enterprise?
Then Logpull and Logpush (except Workers Trace Events on the Workers Paid plan) aren’t options. Your history lives in the analytics datasets, and each one has its own retention limit. Check your exact limits and archive the data before it expires.
Keep history without polling jobs
MetricKeeper connects with a read-only API token and archives the analytics Cloudflare exposes for your plan, so you don’t have to own a polling job or storage stack.