Workers Observability

Cloudflare’s built-in logging and tracing for Workers: turn it on in wrangler.jsonc and every invocation, console.log and binding call is stored and queryable in the dashboard, or exported over OpenTelemetry.

What it is: Logs
Used for: Distributed tracing
Type: Commercial product
Made by: Cloudflare, Inc.
License: Proprietary
Facts checked: 12 October 2026

What it is

Workers Logs collects three kinds of events with no agent to run: one invocation log per request (method, URL, response, CPU and wall time), anything your code prints with console.log, and errors and uncaught exceptions. New Workers have it on by default; for others you set observability.enabled in the Wrangler config. Logging objects instead of strings, as in console.log({ user_id: 123 }), makes each key a field you can filter and group on. The Query Builder in the dashboard runs aggregations (counts, percentiles, group by) across all Workers in an account, and Issues groups recurring failures.

Traces add automatic instrumentation built into the workerd runtime. Each handler call, outbound fetch(), binding call (KV, R2, Durable Objects and others) and RPC call becomes an OpenTelemetry span, with no SDK in your code; you can add custom spans. Logs and traces each have a head_sampling_rate from 0 to 1, and both can be exported over OpenTelemetry to tools like Honeycomb, Grafana Cloud or Axiom, with persist: false to skip storing them at Cloudflare. Older routes out remain: real-time logs (wrangler tail), Tail Workers that run your own code on events, and Logpush. Data is kept for seven days (three for Workers Logs on the Free plan).

Why teams pick it

Nothing to install: invocation logs, console output and exceptions are captured by the platform, and tracing needs only a config flag
Structured JSON logs are indexed by key with no cardinality limit on fields, so you can group by user ID or path
Tracing is automatic for fetch, binding and RPC calls, follows OpenTelemetry, and exports to any OTLP destination
Head-based sampling for logs and traces separately keeps volume and cost in check on busy Workers

Watch out for

Retention is seven days at most, with longer periods only planned, so history beyond a week needs an export
Up to 5 billion logs per account per day, after which only 1% are kept for the rest of the day; a single log is truncated at 256 KB
Pricing changes on December 1, 2026 from per-event (20 million logs a month included on Paid, then $0.60 per million) to per-GB: 50 GB of ingestion and 10 GB-month of storage included on Paid, then $0.25 per GB and $0.10 per GB-month; Free gets 0.5 GB a day
Tracing is still in open beta: span and attribute names may change, trace IDs are not yet propagated to services outside Cloudflare, and non-I/O spans can show 0 ms because the runtime’s clock only advances on I/O

Alternatives

What all logs have in common →

FluentdOpen sourceA CNCF graduated log collector that tags each event, routes it by tag through plugins, and buffers it until the destination accepts it.

LogstashOpen sourceElastic’s JVM-based pipeline that takes events in, parses them with filters such as `grok`, and sends them on, most often to Elasticsearch.

How it fits with other technologies

What Workers Observability uses

wrangler.jsonc: keep 60% of logs and trace 5% of requests · json

{
  "name": "checkout",
  "main": "src/index.ts",
  "compatibility_date": "2026-10-12",
  "observability": {
    "logs": {
      "enabled": true,
      "head_sampling_rate": 0.6
    },
    "traces": {
      "enabled": true,
      "head_sampling_rate": 0.05
    }
  }
}

See it in a real stack

No architecture uses Workers Observability yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2024–2026

Seeing what a deployed Worker did used to mean streaming logs live or pushing trace event logs elsewhere with Logpush, and tracing meant wiring several OpenTelemetry libraries into your code by hand. In 2024 Cloudflare set out, in its words, “to build the best first-party observability for any cloud platform”: a new metrics dashboard, Workers Logs to ingest and store logs automatically, rebuilt real-time logs and a query builder.

On April 9, 2025 Rohin Lohe announced Workers Observability, a dashboard section for querying logs across all Workers in an account, with Workers Logs generally available and the Query Builder in beta. On October 28, 2025 automatic tracing entered open beta, instrumenting every I/O operation through the workerd runtime so no code changes were needed, with OpenTelemetry export for traces and correlated logs.

On October 2, 2026 Cloudflare folded Workers Observability into one platform-wide Logs home alongside Log Explorer, added custom alerts, dashboards and Cloudflare-wide traces, and announced a single per-GB price for all logs and traces, effective December 1, 2026.

Why it’s built this way

Structured logs over text: Workers Logs indexes the fields of JSON log lines, so questions nobody predicted when writing the code can still be answered by filtering and grouping on high-cardinality fields.
Instrument in the runtime, not the app: Manual OpenTelemetry setup meant several libraries and wrapping every database and API call. Because Cloudflare controls workerd, it can emit spans for every I/O operation automatically.
Price by volume instead of event count: Logs and traces vary widely in size, so the 2026 model charges for gigabytes ingested and stored rather than the number of events.

Timeline

2024
Workers Logs, a new metrics dashboard and rebuilt real-time logs
2025
Workers Observability launches on April 9; Workers Logs generally available
2025
Automatic tracing in open beta on October 28
2026
Unified Cloudflare Observability announced on October 2; per-GB pricing from December 1

Sources6 · facts checked 12 October 2026

Improve this page on GitHub