Cloudflare Traces is now available in open beta, extending the automatic tracing previously limited to Workers across the full request path. A single trace can capture supported security rules, transformations, cache decisions, routing, Worker execution and origin handling, then continue through services on Cloudflare, at your origin, or anywhere else in your stack. The company frames the release as a long-term investment in OpenTelemetry.
Tracing is enabled per domain in the Cloudflare dashboard, or an agent can configure it. No plugins, config or special instrumentation are required — once tracing is on, spans are generated automatically.
From internal tooling to automatic platform spans
Cloudflare's own investigators rely on internal traces that can hold thousands of spans for a single request, produced by dozens of services and features. Workers Tracing was the first move to expose that layer, adding automatic instrumentation for Worker invocations including outbound fetches and calls to KV, R2, D1, Durable Objects and other Workers. Traces extends the same visibility to anyone with Cloudflare in front of an origin or building on the platform, whether or not they write Workers code.
Reading a request as spans
Each supported step along the request path is recorded as a span carrying timing, outcome and relevant attributes, so a request can be inspected in one place rather than reconstructed from logs and configuration. For example:
- Security actions. Custom and managed rules appear in ruleset phase spans that show when evaluation happened, how long it took, and the action taken. Span events identify the rule behind a block or challenge.
- URL rewrites. The
http_request_transformspan lists each change, the request component affected, the rule responsible, and where the transformation sat relative to routing and origin handling. - Routing. The
workers_routingspan indicates whether a route matched, which routing type applied and the matching pattern. - Caching and origin time. Nested cache, upstream and origin spans break down where time went. One example shows a cache miss to origin consuming 527ms of a 539ms response.
Sampling and Trace Rules
A domain-level baseline sampling rate balances visibility, data volume and cost — 1% is a typical steady-state value that still gives continuous coverage of request behavior. Trace Rules let you keep that baseline while capturing full traces for a specific investigation: a hostname, source IP or identifying request header can be traced at 100%, or a temporary debug header can be traced fully while all other traffic stays at the baseline. Trace Rules use the Cloudflare Rules language and can target paths, methods, headers, IP addresses, geographies or combinations of these.
Distributed tracing and export
Cloudflare Traces accepts a W3C traceparent header from an incoming request, so its spans can join a trace started before the request arrived; an incoming propagation policy decides whether that context is accepted. Cloudflare can also forward a new traceparent header to your origin, letting other instrumented services continue the trace through APIs, databases and services on Cloudflare or elsewhere. Sending Cloudflare and application spans to the same OpenTelemetry-compatible backend presents the whole path as one connected trace.
Cloudflare spans are exportable over OTLP to a compatible observability platform, alongside telemetry from the rest of the stack. An account-level destination is configured first, then domains are chosen to send traces to it.
Agent-driven investigation
Coding agents debugging a production issue can inspect code and run tests, but often cannot see what happened to the request in production. Through the Cloudflare Observability MCP server, an agent uses the SQL API to query traces and other observability data. It can locate relevant requests, compare failed traces with successful ones, find where their spans diverge, then connect those findings to repository code to narrow down a fix for review.
Pricing
Cloudflare Traces falls under the unified Cloudflare Observability pricing model, which charges on observability data ingested and retention time rather than spans or events. The new pricing takes effect across Cloudflare Traces and Workers Tracing on December 1, 2026.
Plan | Included Usage | Retention | Additional Usage |
|---|---|---|---|
Free | 0.5 GB of ingestion per day | 7 Days | Not available |
Paid and Enterprise | 50 GB of ingestion | Up to 1 year | $0.25 per GB ingested |
Planned after beta
- Broader automatic instrumentation across the HTTP request path (DDoS rules, Access) and the Workers execution path (Workflows, Queues, Pipelines).
- Authenticated context propagation, allowing trusted callers to continue an existing trace without accepting context from every incoming request.
- Ad hoc tracing to capture a specific request on demand without changing the baseline sampling rate.
- Further OpenTelemetry API support in Workers, including adding attributes to existing spans or retrieving trace context.
- Retention of up to 365 days for longer investigations.
Cloudflare Traces is available from the dashboard, through the API or with Terraform, with OTLP export to a destination.
