A request returns a 403, but your application logs show nothing. Or it takes half a second to respond, while your handler finishes in a fraction of that time. Between the browser and your code sit security rules, URL transforms, caches, routing decisions, and perhaps a Worker. On October 2, Cloudflare introduced Cloudflare Traces in open beta to expose the supported steps in that path as a timeline of spans.
The interesting question is not whether tracing is useful. It is whether the trace tells you which layer deserves attention—and where its measurements stop.
What the Edge Can Now Show#
Once you enable Traces for a domain, Cloudflare can automatically record supported operations without adding instrumentation to your application. A trace may include security-rule evaluations, request transforms, cache handling, Worker routing, and origin connections. The span reference is explicit that spans appear only when the corresponding operation runs; an absent span is not proof that the entire product or configuration is absent.
Imagine an API request that unexpectedly fails. Start with its trace and inspect the ruleset-phase spans: did a custom or managed rule block or challenge it? If it reached the application but landed on the wrong route, inspect http_request_transform for rewritten components and workers_routing for the matched route. Cloudflare’s launch walkthrough shows these investigations in the trace view rather than asking you to reconstruct the sequence from separate dashboards.
Latency needs the same care. A cache span can include fetching or revalidation and transfer of the full response body, not just lookup time; a dynamic span can include connection setup, upload, waiting, and response transfer. Neither is a clean measurement of how long your origin handler ran. That distinction matters before you blame an application for a slow edge-to-client request. It also complements the broader OpenTelemetry observability story: tracing is most useful when its span boundaries mean what you think they mean.
Reproduce One Failure Without Tracing Everything#
Cloudflare’s configuration guide describes a default sampling rate per domain and ordered Trace Rules that override it for matching traffic. A practical first pass is a low baseline rate for normal requests, then a temporary rule with a higher rate for the affected hostname, path, or identifying header. The first matching rule wins, so check its position before assuming a later rule will take effect.
For example, when a customer reports intermittent failures on one API route, enable tracing for that domain, deploy a narrowly matched rule, reproduce the request, and search the resulting traces by its Ray ID or filters. Compare a failed trace with a successful one: the first span where their paths diverge is a better starting point than a speculative code change. Remove or reduce the temporary rule when the investigation ends; tracing more traffic means ingesting more telemetry.
Traces help distinguish a routing or cache mistake from an application bug before anyone starts rewriting the handler.
Connecting Cloudflare to Your Application Trace#
Edge spans alone cannot explain what happened inside an uninstrumented origin. Cloudflare supports W3C traceparent context, but incoming propagation defaults to Reject. Accepting a caller’s context and forwarding context to the origin are separate settings; forwarding a header does not instrument the origin or create application spans by itself.
If your application already emits spans, configure the propagation you need and send both Cloudflare and application telemetry to the same OTLP-compatible destination. Then an edge cache miss and the downstream work it triggers can be inspected together. The earlier OpenTelemetry logs discussion explains why correlating signals across a request is more valuable than merely collecting more of each signal.
Treat external trace context as a trust decision, not just a convenience switch. Cloudflare calls authenticated context propagation a future capability in the October 2 announcement; do not assume it is already part of this beta. Keep the incoming policy deliberate, particularly for publicly reachable domains.
Know the Beta’s Boundary and Cost#
Cloudflare describes this as an open beta with spans for supported request-path operations, not complete visibility into every Cloudflare feature. Its published span list and the launch post distinguish current coverage from planned additions such as broader DDoS and Access instrumentation and ad hoc tracing. If a step you want is absent, check the supported-span list before drawing conclusions from an empty timeline.
There is also a storage decision. The configuration docs let you persist traces for dashboard inspection, export them to an OTLP destination, or do both; exported-only traces will not appear as saved traces in the Cloudflare dashboard. Cloudflare says the unified observability pricing model takes effect on December 1, 2026 and is based on ingested and stored volume rather than simply counting spans. Before raising a sample rate across a busy domain, estimate what that will retain or export.
My Take#
Cloudflare Traces is most valuable when it stops the wrong debugging session from starting. A 403 caused by a security rule does not need a code fix; a slow dynamic span does not, by itself, prove a slow database query. Seeing the request’s supported edge operations in order makes both mistakes less likely.
I would start with one reproducible incident: enable tracing on the affected domain, sample narrowly, inspect the span boundaries, and only then join it to an instrumented origin. If the team can consistently identify where a request changes course, the beta has earned its place in the incident workflow. If not, collecting every span will only produce a larger bill and a more elaborate mystery.
