Cloudflare announced the availability of Cloudflare Traces in open beta, extending automatic tracing from the Workers environment to the rest of the request path within the Cloudflare platform. The service displays the stages of request processing in a single trace, including security rules, transformations, caching, routing, Workers execution, and the connection to the origin, with the ability to follow the trace to other services within the technical infrastructure.
A Unified View of the Request Path
Cloudflare records each supported step as a span containing timing, outcome, and relevant attributes. This enables the team to determine why a request was blocked or challenged, identify the security rule that took the action, and inspect the modifications performed by Transform Rules before the request reaches the application.
The service also shows whether the path passed through Page Rules, Snippets, or Workers, and separates the time spent in Cloudflare from the time spent connecting to the origin and application. It displays caching and origin connection details, including cache miss states; the source cites an example in which the request took 527 milliseconds out of 539 milliseconds to obtain the response from the origin.
Control Over Tracing Scope
The service requires no special configuration or additional tools. After it is enabled on the domain, Cloudflare automatically generates traces. A basic sampling rate can be configured, such as tracing 1% of requests during normal operation, and Trace Rules can then be used to increase coverage to 100% for traffic matching specific conditions, such as a hostname, IP address, or particular header.
Trace Rules use the same rule language as Cloudflare, allowing targeting of paths, HTTP methods, headers, IP addresses, geographic locations, or combinations of them. This gives operations teams a way to isolate a specific problem without increasing the tracing volume across the entire domain.
Integration with OpenTelemetry
Cloudflare Traces can receive the W3C traceparent header from incoming requests, allowing Cloudflare’s spans to join a trace that began in another service. It can also pass a new traceparent to the origin, allowing tracing to continue across APIs, databases, and other services.
The service allows traces to be exported over the OTLP protocol to an OpenTelemetry-compatible destination. To display the Cloudflare trace and application traces as a single chain, the data must be sent to a compatible OpenTelemetry monitoring backend. The Cloudflare Observability MCP server can also enable a software agent to query traces and monitoring data through the SQL API and compare failed requests with successful ones.
What Changes in Practice?
The core value here is reducing the need to reconstruct the request journey from separate logs and configurations. However, current coverage does not include every operation; the service is in open beta, and Cloudflare plans to add spans for DDoS and Access rules and other Workers features later, along with on-demand tracing and broader OpenTelemetry support.
The service falls under Cloudflare’s unified Cloudflare Observability pricing model. The change begins on December 1, 2026: the free plan includes 0.5 gigabytes of data per day with 7-day retention, while paid and Enterprise plans include 50 gigabytes of ingestion and 10 gigabyte-months of storage per billing cycle, with additional fees of $0.25 per gigabyte ingested and $0.10 per gigabyte-month stored. Cloudflare Traces can be used from the dashboard or through the API and Terraform.