Introducing Cloudflare Traces: follow requests through our entire platform
- ID
- 31132
- Status
- summarized
- Published
- 02 Oct 2026, 9:00 PM
- Fetched
- 02 Oct 2026, 10:45 PM
- Provider
- Cloudflare Blog
- Category
- infrastructure
- Original URL
- https://blog.cloudflare.com/cloudflare-tracing/
- Source URL
- https://blog.cloudflare.com/rss/
Summary
- Score
- 6.5
- Created
- 02 Oct 2026, 10:46 PM
- Tags
- Audience
- developerssaas_startup_founders
What happened
Cloudflare launched Cloudflare Traces in open beta, extending automatic tracing beyond Workers to the whole request path — security rules, transformations, cache decisions, routing, Worker execution, and origin handling appear as spans in one request-level timeline. It ships with a baseline sampling rate plus Trace Rules to override per-matching-traffic, W3C traceparent context propagation, in-dashboard timelines, and OTLP export to any compatible endpoint. Cloudflare says its own teams debug with internal traces that can hit thousands of spans per request across dozens of services, and Workers Tracing (with KV, R2, D1 and Durable Objects instrumentation) was the earlier step in exposing that.
Why it matters
If you already run Cloudflare in front of an origin, you can enable tracing per domain in the dashboard with no code changes, which means cache-hit/miss and rule-evaluation decisions stop being guesswork when you're debugging latency. The Trace Rules override matters for cost and noise: you can keep the baseline sampling low and only capture full traces for the traffic you actually care about, and the OTLP export plus W3C traceparent forwarding means these spans can land in your existing backend instead of forcing you onto Cloudflare-only tooling.
Discussion angle
Does the OTLP + W3C traceparent support make this a genuine vendor-neutral option, or is the useful part (cache and rule spans) only visible inside the Cloudflare dashboard — and what would that split mean for how you architect observability?