Cloudflare Traces Opens Proxy Path to OpenTelemetry Spans

Cloudflare Traces has launched in open beta, extending distributed tracing across the edge proxy request path to automatically generate OpenTelemetry spans without manual instrumentation. The release bridges a visibility gap between external clients and backend servers by exposing security evaluations, cache operations, URL transformations, routing logic, Worker invocations, and origin round-trips as structured spans. Alongside this release, Cloudflare announced a structural transition in observability billing: starting December 1, 2026, the company will abandon per-span charges in favor of volume-based pricing governed by data ingestion and retention limits.

Automatic OpenTelemetry Spans Across the Edge Proxy

Distributed tracing has traditionally treated reverse proxies as uninstrumented black boxes. While engineers could trace incoming traffic from the client boundary and resume tracing once requests reached origin microservices, intermediate edge behavior remained opaque. Troubleshooting an edge anomaly previously required correlating disconnected firewall events, audit logs, and page rule configurations.

Cloudflare Traces addresses this limitation by decomposing proxy execution into granular, hierarchical OpenTelemetry spans. Supported stages include:

• cloudflare_request: The root span capturing the entire lifetime of the request at the edge.
• security_rules and firewall evaluation: Spans detailing rule matches, execution duration, and blocking actions.
• cache: Spans tracking cache key generation, lookup outcomes (hit, miss, or bypass), and latency overhead.
• workers_routing and page_rules: Execution spans identifying route matches, URL rewrites from Transform Rules, and edge snippet evaluations.
• dynamic and upstream: Spans measuring origin transport negotiation, time-to-first-byte (TTFB), and response completion.

Because these spans generate automatically within the proxy runtime, platform teams gain fine-grained execution timelines without modifying code or injecting third-party tracing SDKs.

Distributed Context Propagation and Agent-Assisted Debugging

To operate effectively in distributed architectures, Cloudflare Traces implements W3C Trace Context standards. Incoming requests carrying a valid traceparent header can link edge spans directly into an existing upstream trace. Once edge processing concludes, Cloudflare updates and injects the header into origin requests, allowing backend services to maintain trace continuity.

Inbound propagation is governed by configurable security policies. Cloudflare allows administrators to restrict or disable context adoption from untrusted callers, mitigating header spoofing, cache pollution, and trace ID collision risks. Once assembled, traces export over the OpenTelemetry Protocol (OTLP) to any compatible storage backend, configured at the account level and mapped across domains.

The system also interfaces directly with automated diagnostic workflows. Through the Cloudflare Observability Model Context Protocol (MCP) server, external coding assistants can query trace datasets via a SQL API. Agents can compare span divergence across successful and failed requests to isolate latency regressions or configuration errors directly against code repositories, aligning with patterns seen in evidence-grounded agentic operations.

Trace Rules and the December 2026 Volume-Based Pricing Model

Because high-traffic edge networks generate massive telemetry volumes, Cloudflare uses a head sampling engine managed by the Cloudflare Rules language. Infrastructure engineers establish a baseline sampling percentage for regular traffic, then deploy customized Trace Rules to selectively elevate capture rates. Rules can trigger 100% trace capture for specific hostnames, client IP ranges, geographic origins, HTTP request paths, or temporary debugging headers passed during active incident triage.

Controlling sampling rates is essential under the updated commercial model. Cloudflare previously planned to bill on a per-span basis beginning October 1, 2026. However, the company has revised that framework, confirming that effective December 1, 2026, observability pricing will calculate costs based on data volume ingested and storage retention.

Under this structure, infrastructure costs scale with payload throughput rather than span counts. Teams configuring verbose sampling rules must proactively monitor OTLP export sizes to prevent unexpected overages.

What happens next

Cloudflare Traces is currently available in open beta across all domains via the Cloudflare dashboard, REST API, and Terraform provider. As reported by InfoQ, the current beta release represents partial coverage of the edge request lifecycle.

Cloudflare plans to extend automatic span coverage across DDoS protection rules and Cloudflare Access on the HTTP path, as well as Workflows, Queues, and Pipelines within the Workers environment. Forthcoming updates are also scheduled to deliver authenticated context propagation for verified upstream services, ad hoc single-request tracing without adjusting baseline sampling percentages, and native OpenTelemetry API support allowing Workers scripts to inject custom attributes into active proxy spans.