Cloudflare Logpush: What It Ships, What It Costs, and What It Misses

Cloudflare Logpush streams your edge request logs, in batches, to a storage bucket or log platform you own, in near real time and in JSON.

That one sentence covers what most people need to know. The interesting part is everything around it: which plan tier it needs, what the destination costs you every month, which datasets are worth turning on, and the category of logs Logpush will never be able to give you, no matter how it is configured.

What Logpush actually does
The plan tier that gates it
Choosing a destination, and paying for it
Pick your datasets and fields deliberately
The logs Logpush will never have
A setup that covers most teams
How this fits the rest of the stack
FAQ

What Logpush actually does

Logpush is a push pipeline, not a query interface. Cloudflare collects log events at the edge, batches them, and delivers gzipped JSON to a destination you nominate. You do not poll it. You do not query it at Cloudflare. You point it somewhere and the files arrive.

The push frequency is not something you set. Cloudflare pushes as soon as a batch is ready, which in practice means every few seconds to a minute or so depending on volume. You can influence batch size through the API, which matters when your destination has upload limits, but you cannot ask for a nightly digest or a five-minute cadence.

This is the right design for a log pipeline and the wrong mental model if you were expecting a dashboard. Logpush hands you raw events. Turning them into something you can read is the job of whatever sits on the other end.

The practical consequence: budget for the destination, not just the feature. A Logpush job with nowhere good to land is a very efficient way to fill a bucket with files nobody opens.

The plan tier that gates it

Logpush for HTTP request logs is an Enterprise feature. This is the single most common surprise, and it usually arrives after someone has already designed a logging architecture around it.

Some account-scoped datasets are available below Enterprise, and the list has shifted over time, so check the current dataset table against your own plan before you commit. But the headline case, full HTTP request logs for a zone, is the one that needs the top tier.

If you are not on Enterprise, the honest alternatives are worse but real. You can read aggregate analytics in the dashboard. You can use the GraphQL Analytics API for counts and breakdowns rather than individual requests. Or you can log at your origin, which is where most teams end up anyway.

That last option is worth taking seriously rather than treating as a consolation prize. Origin logs and edge logs answer different questions, and for a lot of teams the origin question is the one that actually keeps them up at night.

Choosing a destination, and paying for it

Logpush supports object storage, SIEM platforms, and log management services. The three shapes behave very differently once real volume shows up.

Object storage is the cheapest place to put logs and the most annoying place to read them. Storage is nearly free; querying means standing up something else to read the files.
A log management platform gives you search and dashboards immediately, and bills on ingest volume. At edge-request scale, ingest billing is the line item that grows fastest.
A SIEM is the right answer when the driver is security or compliance rather than debugging. It is rarely the right answer when the driver is a slow page.

Whichever you pick, the cost is a function of how many fields you ship multiplied by how many requests you serve. Both halves are in your control, and most teams only ever adjust one of them.

A busy site can produce tens of gigabytes of request logs a month. If you pipe all of it into a per-gigabyte ingest plan without filtering, the logging bill can quietly overtake the hosting bill. That is not a hypothetical failure mode; it is the normal outcome of leaving the defaults alone.

Pick your datasets and fields deliberately

Logpush exposes several datasets: HTTP requests, firewall events, Workers trace events, audit logs, network analytics, and more. Each one is a separate job with its own field list.

Turn on HTTP requests and you get a long list of available fields, most of which you will never read. Client IP, ray ID, status code, cache status, host, path, user agent, timing figures, TLS details, country, ASN, and a long tail of headers.

A useful starting field set for debugging and performance work:

EdgeStartTimestamp and EdgeEndTimestamp, so you can measure edge time
ClientRequestHost, ClientRequestPath and ClientRequestMethod, so you know what was asked for
EdgeResponseStatus and OriginResponseStatus, so you can separate edge errors from origin errors
CacheCacheStatus, which is the single most useful field for cache work
ClientCountry and ClientASN, for the geography questions
RayID, so a support ticket can be traced back to an actual request

You can add filters to a job too, which is the lever people forget. Shipping only 5xx responses, or only one hostname, cuts the bill by an order of magnitude and keeps the signal. Sample everything, keep all the errors: that is the shape most teams want and almost nobody configures.

The logs Logpush will never have

This is the part worth internalising before building anything on top of it. Logpush sees requests as they pass through the edge. It does not see inside your application.

It will tell you that a request to a checkout endpoint returned a 500 in 4.2 seconds. It will not tell you that the query timed out because a missing index turned a lookup into a table scan. The stack trace, the slow query, the failed third-party call, the log line your own code wrote: none of that is in an edge log, because none of it happened at the edge.

So edge logs answer questions about traffic, caching, geography, bots and status codes. Application logs answer questions about why a specific request failed. Both matter. Only one of them is Logpush.

The failure mode is a team that builds a careful edge-logging pipeline, gets paged about a 500, opens the log platform, and finds a perfect record of the fact that something went wrong with no indication of what. A prototype without logs is a mystery with a URL; a prototype with only edge logs is a mystery with a timestamp.

Which is why runtime logs belong with the thing that is running. On RunxBuild the deploy log and the runtime log for a service sit in the same place, per deploy, so the failing build and the failing request are two clicks apart rather than two systems apart.

A setup that covers most teams

If you are on Enterprise and want something sensible rather than exhaustive, this shape works:

One HTTP requests job, filtered to 4xx and 5xx responses, with the field set above, pushed to a log platform you will actually open.
One HTTP requests job with everything, sampled down, pushed to cheap object storage as an archive you can query later if you have to.
One firewall events job if you run WAF rules, because tuning rules blind is miserable.
Runtime logs staying where the application runs, not in the edge pipeline.

That gives you a searchable error stream, a cheap full archive, and application logs that are still attached to the application. Three systems, each doing the thing it is good at.

Resist the urge to unify all of it into one platform on day one. Unified logging is a fine goal and an expensive first move, and teams that start there usually end up paying ingest rates on data they only look at once a quarter.

How this fits the rest of the stack

Logging is one of those line items that is invisible when you plan the project and obvious when the invoice lands. Edge log delivery, the storage behind it, the ingest cost of the platform reading it, and the compute running the application are four separate numbers that people tend to estimate as one. The RunxBuild hosting calculator lays the infrastructure side of that out as line items, so the service, the database, the storage and the bandwidth each carry their own figure instead of hiding inside a single monthly guess.

Useful related references:

FAQ

Is Cloudflare Logpush free?

The feature itself has no separate per-gigabyte charge from Cloudflare, but HTTP request logs require an Enterprise plan, and you pay whatever your destination charges. Object storage is cheap; log platforms bill on ingest volume, which at edge-request scale is usually the largest part of the bill.

How often does Logpush deliver logs?

Automatically, in batches, as soon as data is ready, typically within a minute. The frequency is not configurable. You can adjust maximum batch size through the API when your destination has upload constraints, but you cannot set a schedule.

What is the difference between Logpush and Logpull?

Logpull is a pull-based API where you request logs for a time range; Logpush delivers them to you continuously without being asked. Logpush is the current recommendation for ongoing delivery, and it scales better because there is no polling loop to maintain.

Can I use Logpush to debug my application errors?

Not really. Logpush records what happened at the edge: the request, the status code, the timings, the cache result. It has no visibility into your application internals, so stack traces, slow queries and your own log lines are not in it. You need runtime logs from wherever the application runs.

How do I reduce the cost of a Logpush pipeline?

Two levers. Cut the field list to the ones you actually query, and add a filter to the job so you ship errors in full and sample the rest. Both are set per job, and together they routinely cut volume by an order of magnitude without losing the signal you care about.