FR
live

Cloudflare unifies its observability stack and opens Traces across the full request path

Cloudflare folds logs, traces, alerts, and analytics into a single platform, and opens Traces in beta to follow a request end to end. Unified pricing lands on December 1, 2026, so audit your log volumes now.

A single amber fiber-optic strand glowing inside a dense bundle of anthracite network cables in a server rack.

October 2, 2026. Cloudflare opens Traces in beta and unveils eight updates that pull logs, traces, alerts, and analytics into a single observability platform. October 2, 2026. The new service emits spans automatically across the full request path — security rules, transformations, cache decisions, routing, Workers execution, and origin handling — with no manual instrumentation. October 2, 2026. Unified log pricing takes effect on December 1, 2026. Why it matters: Cloudflare wants to become “the most observable part of your stack,” and the pricing change forces you to check your log volumes before year-end.

The end of the “which product owns this signal” puzzle

The starting point is simple, and it will feel familiar to any SRE who has ever debugged a request that passed through Cloudflare. The signals for a single request are scattered across separate products — Workers logs over here, firewall events over there, domain analytics somewhere else. Reconstructing what happened means querying each silo with its own language, its own tool, and its own billing model.

Cloudflare is answering by changing the question. Instead of asking “which product owns this signal,” the platform now asks: “what happened along this request path, from the edge to the origin, in a single view?” That is the point of the eight updates announced on October 2, 2026 during Birthday Week, and it is as much a strategic shift as a technical one: observability becomes a cross-platform capability, not a sum of products.

The first building block is the new Logs home, which merges Workers Observability and Log Explorer. One set of tools now covers the HTTP, firewall, Workers, Containers, R2, and AI Gateway datasets. You can start from a latency spike, group by hostname or data center, then switch to another dataset without leaving the screen. Queries run in raw SQL or through built-in filters, and visualizations can be generated in natural language.

Traces: one request, followed end to end

Traces is the centerpiece. Where Workers Tracing — launched last year — was limited to Workers invocations and their outbound calls to KV, R2, D1, or Durable Objects, the new version extends tracing to everything else in the path. In a single trace you can now see which security rules were evaluated, how a Transform Rule rewrote the URL, whether the response came from cache, and where the time went between Cloudflare, the origin connection, and the application.

The example Cloudflare gives is telling: a cache miss that went to origin, where 527 ms of the 539 ms total was spent fetching from the application server. That is exactly the kind of insight that used to require manually correlating separate logs. Now each step is recorded as a span with its timing, outcome, and attributes, and you can answer operational questions directly: “why was this request blocked, and which rule acted?” or “which part of the path added the missing 500 ms?”

Deployment is deliberately frugal. No plugins and no instrumentation to write: once tracing is enabled on a domain, spans are generated automatically. A baseline sampling rate — say 1% of traffic — keeps a continuous window of visibility without collecting a trace for every request. Trace Rules, which reuse Cloudflare’s rules language, let you raise that rate to 100% for a targeted investigation: a hostname, an IP address, or a temporary debug header. W3C traceparent propagation accepts and forwards trace context, and export happens over OpenTelemetry to any OTLP endpoint.

One SQL API and one pricing model

The other structural piece is the unified SQL API, now in beta. Instead of integrating separately with Workers logs, Containers security events, HTTP request logs, and analytics data, a person — or an AI agent — queries everything with one SQL dialect, one authentication model, and one API. The agent can go through the new cf CLI or Cloudflare’s observability MCP server to investigate logs, traces, and analytics. The same SQL surface also arrives inside Workers through a native binding, so a Worker can meter customer usage, build dashboards, or automate incident investigation without configuring a separate API client.

That move is paired with a change that will hit invoices directly. From December 1, 2026, ingested and stored logs and traces move to a unified observability subscription and volume-based pricing: $0.25 per GB ingested and $0.10 per GB-month stored. The free tier includes 0.5 GB of ingestion per day with 7 days of retention; paid and Enterprise plans include 50 GB of ingestion and 10 GB-month of storage per billing cycle, with retention of up to one year announced as next. For a team that logs heavily, the shift from “per event” to “per volume” billing can move the bill either way — which is exactly why you should audit your volumes before the deadline.

Alerts and analytics, finally homogeneous

The consolidation also reaches alerts. The old Notifications module, renamed Alerts, now lets you define conditions directly on anything the unified SQL API can query: HTTP logs, Workers events, Analytics Engine datasets, traces, and security events. You pick a dataset and a condition in SQL, a threshold, anomaly, or SLO, an evaluation window, and a destination — and webhooks are now available on all plans, including routing an alert to an agent that starts investigating immediately.

Finally, domain analytics gain 30-day retention and a unified view, which completes the promise: no more reconstructing a domain’s state from scattered metrics. Taken one at a time, these eight changes are incremental improvements. Taken together, they sketch a platform where the trace becomes the basic unit of investigation, and SQL becomes the common language of observability.

The observability gravity play

There is a strategic read here too. Cloudflare already sits in front of a large share of the internet’s traffic, and it is now turning that position into an observability business: instead of asking customers to export telemetry to a separate vendor and reconcile two views of the same request, it answers the question where the request already is. For SRE teams drowning in tool sprawl, the appeal is real — one fewer integration, one fewer pricing model, and a trace that spans from the edge to the origin without stitching logs together by hand. The counterweight is vendor concentration: the more of your visibility lives inside Cloudflare, the more expensive a future migration becomes.

Verdict

If you are already on Cloudflare and debug multi-hop stacks — WAF, transformations, Workers, origin — enable Traces in beta and wire up the unified SQL API: they remove the main friction, which is reconstructing a request from fragmented logs. Before December 1, 2026, model your log and trace volume against the new rates ($0.25/GB ingested, $0.10/GB-month) to avoid a billing surprise, especially if you log heavily. If you are on another CDN, this shift is one more argument for Cloudflare’s observability gravity: the platform your requests already pass through becomes the one that best shows you what they did.

References

The cyber brief, every Tuesday

The flaws that matter and the patches to apply, in a ten-minute read.

No spam. One-click unsubscribe.
read next

On the same topic

← Back to the feed

Type at least two characters.

↑ ↓ navigate ↵ open esc dismiss