If you run anything behind Cloudflare, you’ve probably done this dance: a request fails or slows down, and you stitch together an answer from three places. Which security rule fired? Did a Transform Rule rewrite the URL? Was it a cache miss? How long did the origin take? Each answer lives in a different log or dashboard tab.
Cloudflare Traces, announced on October 2, 2026 in open beta, collapses that into a single request-level timeline. According to Cloudflare’s announcement, one trace now shows supported security rules, transformations, cache decisions, routing, Worker execution, and origin handling — no instrumentation, config, or plugins required.
What actually gets captured
Each supported step in the request path becomes a span with timing, outcome, and attributes. Concretely, that means you can open a trace and see which security rule blocked or challenged a request and how long rule evaluation took, inspect the http_request_transform span to see exactly what a Transform Rule changed, check workers_routing to confirm which route matched, and expand nested cache and origin spans to see where the time went. Cloudflare’s example shows a cache miss spending 527ms of a 539ms request waiting on origin — the kind of answer that previously required correlating multiple logs.
This builds on Workers Tracing, which Cloudflare shipped last year to automatically instrument Worker invocations plus calls to KV, R2, D1, Durable Objects, and other Workers. The new product extends that same approach to the whole platform, whether Workers are in your path or Cloudflare just fronts an origin.
Sampling that fits real investigations
The design choice I find most practical is the two-layer sampling model. You set a low baseline — say 1% of requests — for continuous visibility, then use Trace Rules to override it for specific traffic. A customer reports an issue? Trace 100% of their hostname or source IP while everyone else stays at baseline. Debugging something odd? Trace requests carrying a temporary debug header. Trace Rules use the same Cloudflare Rules language as everything else, so you can target by path, method, header, IP, or geography.
Traces also participate in distributed tracing proper: Cloudflare accepts W3C traceparent headers on incoming requests and forwards a new one to your origin, so instrumented services downstream can continue the trace. Export goes over OTLP to any compatible backend, keeping the data portable.
The agent angle
The other notable piece: through the Cloudflare Observability MCP server, a coding agent can query traces via the SQL API. Cloudflare’s framing is that an agent debugging a production issue could compare failed traces against successful ones, find where the spans diverge, and — since it can also read your repository — connect that divergence to the code that needs changing. I’ve written before about Cloudflare turning telemetry into something agents can query, and this is a natural continuation: the investigation loop, not just the dashboards, is becoming programmable.
Pricing and caveats
Traces will use Cloudflare’s unified observability pricing, based on ingestion volume and retention rather than span counts, effective December 1, 2026. The free tier includes 0.5 GB of ingestion per day with 7-day retention; paid and Enterprise plans get 50 GB of ingestion with $0.25 per additional GB and $0.10 per GB-month stored, with up to a year of retention on the roadmap.
It’s an open beta, so the span coverage is not complete yet — Cloudflare lists broader instrumentation (DDoS rules, Access, Workflows, Queues), authenticated context propagation, and ad hoc request tracing as upcoming. If most of your latency lives in one slow origin call or one over-eager security rule, this is worth enabling now and checking which of your actual questions the traces can already answer.