Cloudflare Traces follows a request across its whole network

Cloudflare has opened Cloudflare Traces in beta, extending automatic tracing beyond Workers to the rest of the path a request takes through its network. The feature was announced on 2 October 2026.

In a single trace, developers can now see supported security rules, transformations, cache decisions, routing, Worker execution and origin handling, and then continue that trace into services running on Cloudflare, at their own origin, or elsewhere in the stack.

What Traces actually does

The feature automatically traces requests across Cloudflare and captures supported platform operations on one request-level timeline, with no extra setup. Developers can set a baseline sampling rate and then use Trace Rules to raise or lower it for matching traffic, which keeps the cost of tracing under control on busy domains.

Trace context also propagates end to end: Traces accepts and forwards W3C traceparent headers, so a request that starts outside Cloudflare can be followed as it moves through it. Inside the dashboard, developers get request timelines and span details, and spans can be exported to any endpoint that speaks the OpenTelemetry Protocol.

Why OpenTelemetry is the point

Cloudflare is blunt that this is a long-term investment in OpenTelemetry rather than a proprietary format. That matters more than it sounds. Most teams already have an observability vendor and a set of dashboards, and they have limited appetite for a second, incompatible view of the world. Exporting through an OTLP endpoint means Cloudflare's traces can land in the tooling a team already uses instead of forcing a migration.

Traces can be enabled per domain in the dashboard, and the beta is open now.

Our opinion

Edge platforms have spent years telling developers that the interesting work happens at the edge without giving them much to see once a request leaves their Worker. Cloudflare Traces is an admission that a platform you cannot observe is a platform you cannot fully trust, however fast it is. Wiring traces through cache decisions and security rules is the genuinely useful part: those are precisely the places where a request can be altered or blocked, and they are usually the blind spots in an incident. Choosing OpenTelemetry over a branded SDK is the right instinct too, because it lowers the cost of leaving. Traces will not fix a bad architecture, but it removes one of the better excuses for not knowing what yours is doing.