Cloudflare Traces links security rules to request delays
Cloudflare Traces is designed to show website and application teams how security checks, routing decisions and other supported operations affect an individual web request. In an announcement dated October 2, 2026, Cloudflare describes automatically generated traces, connected records of a request's journey, that can help explain both unexpected blocks and slow responses. The transferable lesson is straightforward: investigating a problem becomes easier when teams can connect decisions and timing across services rather than piece together separate records.
The announcement, by Mar Witek, Dan Lapid, Nevi Shah and Daniel Walsh, describes an effort to expose more of the visibility Cloudflare uses internally. According to the authors, its own investigations often involve traces containing thousands of spans generated by dozens of services and features. A span records one operation within a trace, including details such as its duration and result. Cloudflare Traces aims to extend that visibility both to applications built on its platform and to websites that use Cloudflare in front of an origin, the server hosting the underlying application.
This builds on Workers Tracing. Cloudflare says it introduced automatic instrumentation, the recording of operations without developers adding tracking code for each one, the previous year. That covered invocations of Workers, programs running on Cloudflare's platform, including outbound fetches that request data from other services. It also covered calls to KV, its key-value data store; R2, its object storage service for files and other data; D1, its database service; Durable Objects, which coordinate application state; and other Workers. That earlier functionality showed activity inside the Workers runtime, the environment executing those programs.
A request's path, not just its final result
A request can encounter security rules, transformations that change its contents, routing that selects its destination, caching that reuses a stored response, or forwarding to another service. Cloudflare says Traces records each supported step with timing, outcome and relevant attributes. The qualification matters: the supplied announcement describes supported operations, not proof that every possible platform operation is visible.
For security investigations, the traces show when custom or managed rules examined a request, how long that took and which action followed. Events within a span identify the rule that blocked a request or issued a challenge, a check intended to distinguish legitimate visitors from unwanted traffic. This gives website teams a more specific basis for investigating access complaints than the final blocked response alone.
For changes to a web address, the http_request_transform span shows what a Transform Rule altered, which part of the request changed and which rule was responsible. It also locates that change relative to routing and origin handling. The announcement discusses identifying which Page Rules, Snippets or Workers handled or changed traffic. Its workers_routing span reports whether a route matched, the routing type used and the matching route pattern, the address-matching condition that selected a route.
Performance investigations use nested cache, upstream and origin spans, records of stored-response handling and communication with services further along the request path. In Cloudflare's example, a cache miss, meaning no reusable response was available, sent the request to the origin. Getting a response accounted for 527ms of the 539ms shown. That is a specific illustration from Cloudflare, not a general performance measurement or a result measured by AEU Data.
Collect selectively, investigate precisely
Cloudflare says its platform spans require no special instrumentation or plugins once tracing is enabled for a domain, the website name being monitored. Teams can set a baseline sampling rate, the proportion of requests recorded, to balance visibility against data volume and cost. The announcement gives 1% during routine operation as an example, not a recommended setting for every website.
Trace Rules allow narrower investigations without raising collection across the whole domain. Cloudflare describes recording 100% of traffic for a particular hostname, source IP address or identifying request header while leaving other traffic at 1%. A hostname identifies a particular site or service, an IP address identifies a network connection, and a header carries information alongside a request. Another example uses a temporary debug header to mark requests for investigation while all other traffic stays at the baseline.
These controls use the existing Cloudflare Rules language, its syntax for expressing matching conditions. Teams can select requests by paths, methods, headers, IP addresses, geographies or combinations of those properties. Paths identify requested locations within a site; methods describe the requested action. The broader operational principle is to gather detailed evidence for a reproducible problem without unnecessarily collecting the same volume for unrelated visitors.
Connecting Cloudflare to the rest of the application
Distributed tracing links a request across multiple systems. Cloudflare Traces can accept an incoming W3C traceparent header, a standard field carrying identifiers that associate operations with a shared trace. An incoming propagation policy determines whether Cloudflare accepts that context, allowing its spans to join a trace started before traffic reached the platform.
Cloudflare can also send a new traceparent header to the origin. Other instrumented services can read it and continue the trace through application programming interfaces (APIs), connections between programs, as well as databases and services hosted on Cloudflare or elsewhere. This does not mean external applications automatically become observable: those services must be instrumented to continue the record.
To display the result as one connected trace, Cloudflare says teams can send both its spans and application spans to the same OpenTelemetry-compatible backend, a collection and analysis system supporting the open framework for operational data. Export uses OTLP, the OpenTelemetry Protocol for transmitting that data. Administrators configure a destination at account level and choose which domains send traces there.
The supplied announcement ends during its export discussion. It does not establish pricing, retention periods or further availability conditions, so those details remain unspecified here. For businesses seeking help with the surrounding infrastructure, AEU Data provides managed cloud and data infrastructure with monitoring, relevant to maintaining visibility into the systems behind a website, rather than a claim of integration with this announcement.