Cloudflare Traces enters open beta and turns the proxy layer into OpenTelemetry spans

From the edge to the server, now with spans

Cloudflare has put the Traces feature into open beta, according to an InfoQ report published on October 10, 2026. The feature extends the automatic tracing capture that already existed in Workers to the rest of a request's path: security rules, transformations, cache decisions, routing, Worker execution, and origin handling now appear as OpenTelemetry spans on a single timeline per request, without needing to write instrumentation.

This closes a known gap for anyone running distributed tracing behind a proxy. Before, the trace showed the client on one side and the application on the other, with everything happening in between inferred from logs and configuration. Now each supported stage arrives as a span with its own execution time, outcome, and attributes.

The questions Cloudflare uses as examples are the same ones that generate support tickets: which security rule blocked the request, and how long did it take to evaluate the rule? Did a Transform Rule rewrite the URL before it reached the application, and at what point did that happen relative to routing? Which Page Rule, Snippet, or Worker handled the request, and which route pattern matched?

Where the request spends its time: an example

Cloudflare illustrates the gain with a cache miss case: of a 539ms request, 527ms were spent waiting for the response to come back from the origin. Without the nested cache, upstream, and origin spans, that distinction stays invisible: the team only sees that the request was slow, not where the time went.

For anyone debugging production, this granularity changes the investigation flow. Instead of opening cache logs, then routing logs, then origin metrics to piece the story together manually, Traces' single timeline already delivers the sequence ready-made, span by span. In practice, this reduces the number of separate systems a team needs to open during a latency investigation, since WAF, CDN, and application now speak within the same trace.

Propagated context and rule-controlled sampling

The feature accepts the W3C standard traceparent header coming from an inbound request, which lets Cloudflare's spans join a trace started upstream, and it can forward a new traceparent to the origin so instrumented services continue the same trace. An inbound propagation policy decides whether Cloudflare accepts context from external callers, which matters because accepting a trace ID from any client opens room for noise.

Sampling runs on the same rules engine used elsewhere in the platform. The team sets a base rate, say 1% during normal operation, and writes Trace Rules that override that rate for specific traffic. One example Cloudflare cites traces 100% of requests from a hostname, origin IP, or identifying header for a specific customer, while the rest stays at the base rate. Another example captures every request carrying a temporary debug header during an investigation. Rules can target path, method, header, address, geography, or combinations of these.

Spans are exported via OTLP to any compatible backend. The team configures a destination at the account level and chooses which domains send data to it, which keeps telemetry portable across observability tools instead of locking the data inside the Cloudflare dashboard.

Code agents enter the observability mesh

There's also an agent angle: through the Cloudflare Observability MCP server, a code agent can query traces using the SQL API, compare failed traces against successful ones to find where the spans diverge, and connect that finding back to the code in the repository. InfoQ notes that this follows up on the agent-focused tracing work Cloudflare itself had shown in August 2026: telemetry becomes something an agent reads, not just a dashboard a person watches.

In practice, this opens the door to AI-assisted debugging that doesn't depend on the developer manually copying and pasting trace IDs: the agent already has the query ready to pull the right context via the SQL API.

The price changes again, and this time it hits harder

Anyone already using Workers Tracing needs to pay attention: this is the second pricing change in two months. InfoQ's coverage from August 2026 had reported that each span would become a billable event starting October 1, 2026. That model is now being replaced, starting December 1, 2026, with billing based on ingested data and retention.

The free plan includes 0.5GB of ingestion per day with seven days of retention, with no additional usage available. Paid and Enterprise plans include 50GB of ingestion and 10GB-month of storage per billing cycle, with additional usage priced at US$0.25 per GB ingested and US$0.10 per GB-month stored. Retention of up to one year is listed as "coming soon".

Billing by volume instead of by span is the more significant half of the change. Sampling decisions now map directly to the bill, which explains why Trace Rules have the shape they have: keep the base rate low and raise it only for traffic under investigation. Teams that today trace everything in a staging environment will feel this ingestion cost more directly than they did under the per-span model.

What isn't covered yet

Coverage is partial by design, and Cloudflare itself lists what's missing. On the HTTP request path, broader automatic instrumentation is planned for DDoS rules and Access. On the Workers execution path, Workflows, Queues, and Pipelines still need coverage.

Also on the roadmap: authenticated context propagation, so trusted callers can continue a trace without Cloudflare accepting context from just anyone; ad hoc tracing of a specific request without changing the base rate; and support for the OpenTelemetry API inside Workers to add attributes to existing spans.

Traces is available in open beta through the dashboard, the API, or via Terraform, on any domain, with export to an OTLP destination.