deniz.in

Markets

Weather

Loading weather

· via Cloudflare blog

Cloudflare opens Traces beta and unifies logs, traces and analytics into one platform

Cloudflare's Traces, now in open beta, follows requests through its edge and origin as OpenTelemetry spans, part of eight updates unifying logs, traces, analytics and alerts under one pricing model.

Cloudflare opens Traces beta and unifies logs, traces and analytics into one platform

Cloudflare has launched Traces in open beta, a distributed tracing feature that records a request's journey through the company's network — security rules, transformations, routing, cache decisions, Worker execution and origin handling — in a single timeline. The announcement, published on the Cloudflare blog, came alongside a companion post describing eight updates that consolidate logs, traces, analytics, alerts and dashboards into one observability platform with a unified pricing model.

What Traces captures

According to Cloudflare, once tracing is enabled for a domain, spans are generated automatically, with no instrumentation, plugins or extra configuration required. Each supported step in a request's path is recorded as a span with its timing, outcome and attributes.

The feature targets questions that previously required reconstructing events from separate logs and configuration screens. Cloudflare cites examples such as identifying which security rule blocked or challenged a request, checking whether a Transform Rule rewrote the URL before it reached the application, seeing which route matched to invoke a Worker, and determining whether a response came from cache or origin. One illustrative trace in the post shows a cache miss where 527ms of a 539ms response was spent waiting on the origin.

Traces extends Workers Tracing, which Cloudflare introduced earlier and which automatically instruments Worker invocations, including calls to KV, R2, D1, Durable Objects and outbound fetches. The company notes that its own internal debugging relies on similar traces, sometimes containing thousands of spans from dozens of services.

Sampling, rules and trace propagation

Users set a baseline sampling rate — Cloudflare suggests around 1% of requests for continuous visibility — and can override it with Trace Rules for targeted investigations. For instance, 100% of traffic matching a particular hostname, source IP or request header could be traced while all other traffic stays at the baseline. Trace Rules use the same expression language as other Cloudflare rules, allowing targeting by path, method, header, IP or geography.

The feature also accepts the W3C traceparent header, so spans generated inside Cloudflare can join a trace that started before the request reached the edge, controlled by a propagation policy. Cloudflare can forward a traceparent header to the origin so downstream services can continue the trace. Spans are represented as OpenTelemetry data and can be exported over OTLP to any compatible observability backend, configured as an account-level destination with per-domain opt-in.

Eight updates to observability

The companion Cloudflare blog post outlines the rest of the platform changes:

  • A unified Logs home that merges Workers Observability with Log Explorer, covering datasets such as HTTP events, firewall events, Workers, Containers, R2 and AI Gateway, with cross-dataset querying planned.
  • A unified SQL API in beta, offering one dialect and authentication model for querying telemetry, accessible through the new cf CLI, the Observability MCP server, or a native Worker binding.
  • Custom alerts, built on the SQL API, supporting threshold, anomaly and SLO conditions, with webhooks now available on all plans.
  • Domain analytics consolidated into one view, with 30 days of retention on every plan.
  • Custom dashboards combining analytics, logs, traces and security events.
  • Logpush, previously Enterprise-only, extended to all self-serve plans.

Agents get an explicit role: through the Observability MCP server, a coding agent can query traces and other telemetry with SQL, compare failed and successful traces, and link where their spans diverge to the relevant code in a repository.

A single pricing model

Traces falls under the new unified observability pricing, which charges by data ingested and stored rather than per span or event. Starting December 1, 2026, the free tier includes 0.5 GB of ingestion per day with 7-day retention and no paid expansion. Paid and Enterprise plans include 50 GB of ingestion and 10 GB-month of storage per billing cycle, with extra usage billed at $0.25 per GB ingested and $0.10 per GB-month stored, and retention of up to one year planned. Cloudflare says the model applies across all plans, effective upon renewal for Enterprise customers, and covers existing Developer Platform logs as well as tracing.

Why it matters

For teams with applications behind Cloudflare, the gap between knowing something went wrong at the edge and knowing exactly where has traditionally required guesswork or stitching together multiple products. Traces makes the edge an instrumented part of the request path, and because it speaks OpenTelemetry and W3C trace context, that telemetry plugs into existing observability stacks rather than staying siloed in Cloudflare's dashboard. Usage-based pricing also removes per-event billing surprises as span volumes grow.

There are caveats: the feature is in open beta, coverage today is limited to supported operations, and broader instrumentation — Cloudflare names DDoS rules and Access — remains on the roadmap. Still, the direction is clear: Cloudflare is positioning observability as a platform-wide capability rather than a collection of per-product tools, and betting that OpenTelemetry compatibility makes its network telemetry useful far beyond its own dashboard.

  • #cloudflare
  • #observability
  • #opentelemetry
  • #distributed-tracing
  • #cloud

Related posts