Workers Logpush: From live tailing to a durable log trail

Cloudflare has expanded its Workers debugging toolbox with Workers Trace Events Logpush, a feature that routes Workers logs to external object storage or analytics platforms. Available to all Workers Paid and Enterprise plan customers, the feature complements wrangler tail with a persistent, queryable record of production activity.

The new capability addresses a common tension in serverless-style platforms: deployment is fast, but observability can lag behind. While local tooling like wrangler dev, Miniflare, and the open-sourced workerd runtime catches many issues before release, some bugs only surface under real production load. Workers Logpush is designed to bridge that gap.

What gets logged

Workers Logpush captures the same categories of data developers expect from server-side logging:

  • Request metadata, including status codes and timing
  • console.log() output from script execution
  • Uncaught exception details with stack traces

A typical log entry contains the full request context needed to trace a specific failure:

{
   "AccountID":12345678,
   "Event":{
      "RayID":"7605d2b69f961000",
      "Request":{
         "URL":"https://example.com",
         "Method":"GET"
      },
      "Response":{
         "status":200
      },
      "EventTimestampMs":1666814897697,
      "EventType":"fetch",
      "Exceptions":[
      ],
      "Logs":[
         {
            "Level":"log",
            "Message":[
               "please work!"
            ],
            "TimestampMs":1666814897697
         }
      ],
      "Outcome":"ok",
      "ScriptName":"example-script"
   }

Logpush supports integrations with major observability backends, including Datadog and New Relic, as well as Cloudflare R2 for低成本 storage and ad hoc querying of historical logs.

Pricing model

The service is priced at $0.05 per million requests, with a monthly inclusion of 10 million requests. Crucially, charges only apply to requests that produce logs delivered to a destination after any filtering or sampling is applied—so heavy filtering can meaningfully reduce cost.

Setup: two steps

Configuration is intentionally minimal:

  1. Create a Logpush job. The example below routes Workers logs to R2 storage:
curl -X POST 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/logpush/jobs' \
-H 'X-Auth-Key: <API_KEY>' \
-H 'X-Auth-Email: <EMAIL>' \
-H 'Content-Type: application/json' \
-d '{
"name": "workers-logpush",
"logpull_options": "fields=Event,EventTimestampMs,Outcome,Exceptions,Logs,ScriptName",
"destination_conf": "r2://<BUCKET_PATH>/{DATE}?account-id=<ACCOUNT_ID>&access-key-id=<R2_ACCESS_KEY_ID>&secret-access-key=<R2_SECRET_ACCESS_KEY>",
"dataset": "workers_trace_events",
"enabled": true
}'| jq .

Filters and sampling rates can be attached to the logpull_options field to control data volume. For instance, to receive only logs where an exception was thrown:

"filter":"{\"where\": {\"key\":\"Outcome\",\"operator\":\"eq\",\"value\":\"exception\"}}"
  1. Enable logging on the Worker script. Add logpush = true to the wrangler.toml file, either at the top level or within a specific environment. Any script with this property is automatically included in the Logpush job.

Full configuration details, including supported destinations and filter syntax, are documented in the Workers Logpush guide.