--- title: "Introducing Cloudflare Traces: follow requests through our entire platform" slug: introducing-cloudflare-traces-follow-requests-through-our-entire-platform url: https://listedarticles.com/articles/introducing-cloudflare-traces-follow-requests-through-our-entire-platform canonical_url: https://blog.cloudflare.com/cloudflare-tracing/ content_type: announcement language: en published_at: 2026-10-02T00:00:00.000Z updated_at: 2026-10-03T03:13:25.348Z author: "Dan Lapid, Daniel Walsh, Mar Witek, Nevi Shah" authored_by: human publisher: "Cloudflare" publisher_url: https://blog.cloudflare.com/ topics: ["Infrastructure", "Developer Tools", "Observability", "Cloudflare", "OpenTelemetry"] license: all-rights-reserved word_count: 1393 reading_minutes: 6 citation: "Dan Lapid, Daniel Walsh, Mar Witek, Nevi Shah, Cloudflare. \"Introducing Cloudflare Traces: follow requests through our entire platform.\" 2 Oct 2026. https://blog.cloudflare.com/cloudflare-tracing/ (all-rights-reserved)" # The full text follows. The web page shows an extract and sends readers # to the source above; quote the citation and link the canonical URL. --- # Introducing Cloudflare Traces: follow requests through our entire platform > Cloudflare Traces enters open beta: automatic request-level tracing across security rules, transformations, cache, routing, Workers, and origin handling, with Trace Rules sampling, W3C context propagation, dashboard inspection, and OTLP export under unified observability pricing. # Introducing Cloudflare Traces: follow requests through our entire platform Mar Witek, Dan Lapid, Nevi Shah, and Daniel Walsh Today, we’re introducing __Cloudflare Traces__ in open beta, extending __automatic tracing beyond Workers__ to the rest of the request path. In one trace, you can see supported security rules, transformations, cache decisions, routing, Worker execution, and origin handling, then continue that trace through services running on Cloudflare, at your origin, or elsewhere in your stack. This is a long-term investment in __OpenTelemetry__ and in making Cloudflare the most observable part of your stack. You can now: - **__Automatically trace requests across Cloudflare__:** Capture supported platform operations in one request-level timeline, no additional set up required. - **Control which requests are traced** : Set a baseline sampling rate, then use__Trace Rules__ to override it for matching traffic. - **End-to-end trace context propagation:** Accept and forward__W3C traceparent headers__ - **__Investigate traces in Cloudflare__:** View request timelines and span details directly in the Cloudflare dashboard. - **__Export traces with OpenTelemetry__:** Send your spans to any destination with a compatible Open Telemetry Protocol (OTLP)__endpoint__ . You can __enable tracing in the Cloudflare dashboard__ on any domain or let your agent set up for you: ## Giving you the visibility we use to debug Cloudflare When our own teams investigate, we use our own internal traces, which often include thousands of spans for a single trace, generated by dozens of services and features. This lets us dig deep into every detail of a given request. We don’t think that visibility should stop at our internal systems. __Workers Tracing__ was our first step toward exposing what happens on our platform. Last year, we launched automatic instrumentation for Worker invocations, including __outbound fetches and calls to KV, R2, D1, Durable Objects, and other Workers__. It shows the work performed inside the Workers runtime without requiring tracing code for every operation. The goal of Cloudflare Traces is to bring the same level of visibility to **everyone** using Cloudflare, whether you’re building on Cloudflare or just have Cloudflare in front of an origin. You get to see how your traffic moved through our platform, and connect the dots between how you’ve configured Cloudflare, and how this influences request processing time, routing decisions, and more.  ## Follow one request end to end A request’s path through Cloudflare can be complicated! It might pass through security rules, transformations, routing, caching, or proxied to another service entirely. Cloudflare Traces __records each supported step as a span__, including its timing, outcome, and relevant attributes. Instead of reconstructing the request from separate logs and configuration, you can see the request’s path through our system in one place. You can answer questions like: ### Why was the request blocked or challenged, and which security rule took action? See when __custom or managed rules__ evaluated the request, how long evaluation took, and the resulting action. Identify the rule responsible for a block or challenge through its span events. ### Was the URL rewritten by a Transform Rule before it reached the application? You can open the `http_request_transform` span to see each change, the request component it affected, and the rule responsible. You can also see where the transformation occurred relative to routing and origin handling. ### Which Page Rules, Snippets, or Workers handled or changed the request? The `workers_routing` span shows whether a route matched, which routing type was used, and the matching route pattern. ### Was the response served from cache, and where was time spent between Cloudflare, the origin connection, and the application? You can expand nested cache, upstream, and origin spans to see where the request spent its time. Here, you can see there was a cache miss that went to origin and spent 527ms of the 539ms getting a response. ## Configure your tracing There is no special instrumentation, config, or plugins required. Once tracing is enabled for a domain, Cloudflare generates these spans automatically. This lets you extend the trace through third-party services and back again by adhering to __open standards__. From there, you can control which requests are traced using a baseline sampling rate and __Trace Rules__. ### Set a baseline sampling rate You can enable tracing on any domain and __set a baseline sampling rate__ to balance visibility, data volume, and cost. You might trace 1% of requests during normal operation, giving you a continuous view of request behavior without collecting a trace for every request. ### Configure Trace Rules __Trace Rules__ let you keep a low baseline sampling rate while capturing complete traces for a specific investigation. If one customer reports a problem, you can trace 100% of traffic for their hostname, source IP, or identifying request header while leaving everyone else at 1%. Or during an investigation, you could trace 100% of requests carrying a temporary debug header, while leaving all other traffic at the baseline. This lets you reproduce an issue without increasing tracing across the entire domain. Trace Rules use the same __Cloudflare Rules language__, so you can target paths, methods, headers, IP addresses, geographies, or combinations of those properties. ### Accept and propagate trace context One of the most common requests we hear is for true distributed tracing: a single trace that follows a request into Cloudflare, through our platform, and onward through the rest of your stack. Cloudflare Traces can accept a __W3C traceparent header__ from an incoming request, allowing Cloudflare spans to join a trace that began before the request reached our platform. An __incoming propagation policy__ controls whether Cloudflare accepts that context. Cloudflare can also __forward a new traceparent header to your origin__. Any other instrumented services can extract that context and continue the trace through APIs, databases, and services running on Cloudflare or elsewhere. To view everything as one connected trace, you can send both Cloudflare and application spans to the same OpenTelemetry-compatible backend. ## Export traces to your observability platform You can export Cloudflare spans over __OTLP__ to a compatible observability platform, where they appear alongside telemetry from the rest of your stack. __Configure an account-level destination__, then choose which domains send traces to it. This is part of our commitment to __OpenTelemetry__: Cloudflare represents request activity as OpenTelemetry spans and delivers them using OTLP, keeping the data portable across observability tools. ## Let your agent investigate Cloudflare Traces When you ask a coding agent to debug a production issue, it might inspect your code and run tests, but it may not be able to see what happened to the request in production. With the __Cloudflare Observability MCP server__, your agent can leverage our __SQL API__ to query your traces (and all of your __observability data__!), giving it access to your investigation production telemetry. Let your agent find the right requests, comparing failed traces with successful ones, and identifying where their spans diverge. Since the agent can also inspect your repository, it can connect those findings to the relevant code, narrow down what needs to change, and help put up a fix for you to review. ## Pricing Cloudflare Traces will be a part of the __unified Cloudflare Observability pricing model__. Instead of charging by the number of spans/events, pricing is based on how much observability data you ingest and how long you retain it. New pricing will take effect across Cloudflare Tracing (and Workers Tracing!) starting December 1, 2026. | Plan | Included Usage | Retention | Additional Usage | |---|---|---|---| | Free | 0.5 GB of ingestion per day | 7 Days | Not available | | Paid and Enterprise | 50 GB of ingestion 10 GB-month of storage per billing cycle | Up to 1 year  (coming soon) | $0.25 per GB ingested $0.10 per GB-month stored | ## What's next Following the open beta, we plan to launch: - **Broader automatic instrumentation:** Add more spans across both the HTTP request path (e.g.__DDoS rules__ ,__Access__ ) and the Workers execution path (e.g. Workflows, Queues, Pipelines). - **Authenticated context propagation:** Let trusted callers continue an existing trace without accepting context from every incoming request. - **Ad hoc tracing:** Capture a specific request on demand without changing the baseline sampling rate. - **OpenTelemetry API support in Workers:**__Continue building out our OpenTelemetry APIs__ to enable adding attributes to existing spans or getting trace context. - **Longer retention:** Keep trace data available for up to 365 days for longer-running investigations. ## Get started Follow the __Cloudflare Traces documentation__ to trace your first request and tune sampling with Trace Rules. Cloudflare Traces is available in open beta from the dashboard, through the API, or with Terraform, with support for exporting to an OTLP destination.