From Scattered Logs to a Single Timeline
Traditional debugging leans heavily on logs — timestamped lines each system writes about what it did. Logs are useful, but they are written independently by every component a request touches, so reconstructing the journey of one specific request means manually stitching together lines from a firewall, a cache, a load balancer, and an application server, trusting that the timestamps line up closely enough to tell a coherent story.
Distributed tracing approaches the same problem differently: instead of many separate diaries, one request gets a single ID that is passed along every step of its journey, and each system that touches it contributes a labeled segment — called a span — describing what happened and how long it took. Strung together, these spans form a trace: a timeline of that one request from start to finish. This approach earns its keep specifically when a request crosses multiple systems and the cause of a slowdown isn’t obvious from any single log file alone.
Cloudflare already offered a version of this inside Workers, its edge-computing product, instrumenting things like outbound fetches and calls to storage services. What’s new is extending that same automatic tracing beyond Workers to the rest of the request path: security rule evaluation, URL transformations, cache decisions, routing, and origin handling can now all show up as spans in one trace, without the customer writing any tracing code.
How a Request Becomes a Trace
flowchart TD A[Incoming request] --> B[Security rules span] B --> C[Cache + routing spans] C --> D[Worker execution span] D --> E[Origin handling span] E --> F[Export via OpenTelemetry]
Each box in that chain is generated automatically once tracing is turned on for a domain — there’s no need to install an agent or sprinkle tracing calls through custom code. A team can then dial how much traffic gets traced: a low baseline sampling rate keeps costs and data volume down, while "Trace Rules" let someone temporarily capture 100% of traffic from one customer’s hostname or a specific debug header, without turning on full tracing for everyone else.
Why a Network Operator Sees a Different Slice of the Picture
It’s worth pausing on why Cloudflare, specifically, can offer this. Standalone observability vendors like Datadog or Honeycomb typically need an agent or instrumentation library installed inside a customer’s own servers or containers to collect telemetry. Cloudflare doesn’t need that for the portion of a request’s life that happens on its own network, because that traffic is already flowing through infrastructure Cloudflare operates — the same edge nodes doing DNS resolution, DDoS filtering, and caching can also record what they just did.
That’s a genuine structural advantage, but it’s also a boundary. Cloudflare Traces can only describe what happens on Cloudflare’s own platform. The moment a request leaves Cloudflare’s edge and heads into a customer’s own backend running on AWS, Azure, or a private data center, the visibility depends entirely on whether that backend is separately instrumented and willing to continue the same trace.
Portability: Why Open Standards Matter Here
This is where Cloudflare’s design choices matter beyond the feature itself. Rather than inventing a proprietary tracing format, Cloudflare represents everything as OpenTelemetry spans — OpenTelemetry being a vendor-neutral standard for collecting traces, metrics, and logs that works the same way regardless of which company’s tools are involved — and exports them using the OpenTelemetry Protocol (OTLP) to whatever backend a customer already uses. On the way in, Cloudflare can accept a W3C "traceparent" header, the open standard for passing trace identity between services, letting its spans join a trace that began before the request ever reached its edge; on the way out, it can generate a new traceparent header for the origin server to pick up.
The practical effect is that a team isn’t locked into viewing traces only inside Cloudflare’s dashboard. They can, in principle, assemble one connected trace across Cloudflare’s edge and their own application code, as long as that application code is also instrumented and sending spans to the same backend. The documentation is candid that this linkage with non-Cloudflare services is still a work in progress rather than a finished guarantee — propagation depends on every hop along the way cooperating, and gaps remain outside Cloudflare’s own network.
What Traces Can Show vs. What It Cannot
| Capability | Status today |
|---|---|
| Security rule evaluation and block/challenge reasons | Shown automatically as spans |
| Cache hit/miss and time spent at origin | Shown, including nested timing breakdowns |
| URL rewrites and Worker/route matching | Shown with the rule or route responsible |
| Full application logic inside a customer’s own non-Cloudflare servers | Not visible unless separately instrumented |
| Span/attribute naming staying fixed over time | Not guaranteed; still open beta |
| Guaranteed end-to-end trace ID linkage with external services | Not yet complete; a known limitation |
| Some Workers-beta span timings | Can show as 0 ms due to current runtime timing behavior |
That last row is a useful reminder not to over-read raw numbers in an early beta: Cloudflare’s own documentation notes that certain spans inside Workers can display 0 ms because of how the runtime currently measures timing, not because nothing happened.
An Observability Platform, Not Just a New Dashboard Widget
Traces doesn’t exist in isolation. Cloudflare has been folding logs, traces, analytics, alerts, dashboards, and export tooling into a single observability product, with one SQL-style query layer sitting across all of it, including an option for AI coding agents to query production telemetry through a dedicated interface. That last piece is worth a note of caution: an agent being able to compare a failed trace against a successful one and point toward relevant code is a research-assistance workflow, not a substitute for a human reviewing and approving the fix.
Pricing is shifting too, moving from charging per span or event toward a model based on how much data is ingested and stored, taking effect in December 2026. Whether that model actually saves money depends heavily on a team’s specific mix of log volume, indexing needs, and existing vendor contracts — reporting comparing Cloudflare’s published rate against competitors like Datadog shows the comparison cuts both ways depending on how much indexing or host-based metering a workload needs.
The Honest Limits
None of this makes Cloudflare a replacement for application monitoring everywhere a company’s code runs. It is, for now, an open beta: span names and the attributes attached to them aren’t finalized, and Cloudflare has signaled more automatic instrumentation, longer retention, and deeper OpenTelemetry support are still coming rather than already shipped. For teams whose traffic already flows through Cloudflare, that’s still a meaningful shortcut — one place to ask what happened to a request, instead of four. For everyone else, it’s a reminder that the edge is only ever one slice of the story, however much easier that slice is now to read.
