Cloudflare Introduces Cloudflare Traces in Open Beta

Cloudflare Introduces Cloudflare Traces in Open Beta Cloudflare has launched Cloudflare Traces in open beta, extending automated request tracing across its entire edge platform to provide visibility into security rules, transformations, caching, routing, and origin execution. Cloudflare Traces automatically creates spans for security evaluations, routing, transformations, caching, and origin handling without requiring custom code. Operators can control tracing volume through baseline sampling and targeted Trace Rules using Cloudflare's rules language. The platform supports W3C trace context propagation and OTLP export, enabling unified distributed tracing across external OpenTelemetry-compatible backends. The service integrates with the Cloudflare Observability MCP server for AI-driven debugging and will adopt a unified ingestion- and retention-based pricing model in December 2026. Platform-Wide Request Visibility Cloudflare Traces expands upon earlier Workers Tracing by automatically instrumenting the entire request lifecycle across Cloudflare's infrastructure. Each step—including rule evaluations, header transformations, routing matches, cache hits or misses, and origin fetch durations—is recorded as an individual span with associated timings and attributes without requiring plugins or manual code. Configurable Sampling and Distributed Context Users can set baseline sampling rates to capture a consistent sample of global traffic, then deploy Trace Rules using Cloudflare's standard rules language to trace 100% of specific IPs, hostnames, or temporary debug headers. Cloudflare Traces also adheres to OpenTelemetry standards, accepting and forwarding W3C traceparent headers and exporting spans via OTLP to external observability destinations. AI Agent Integration and Unified Pricing Through the Cloudflare Observability Model Context Protocol (MCP) server, coding agents can use SQL APIs to query production traces and compare failed executions directly against codebase files. Cloudflare Traces will follow a unified observability pricing framework based on ingested volume and retention rather than span counts, with Free tiers offering 0.5 GB per day and paid tiers starting at $0.25 per additional gigabyte ingested, scheduled to take effect December 1, 2026.

Cloudflare 推出全平台端到端追踪功能 Cloudflare Traces 公测版 Cloudflare 宣布推出 Cloudflare Traces 公测版，将自动链路追踪从 Workers 扩展到整个请求处理路径，涵盖安全规则、请求转换、缓存与回源等环节，并全面支持 OpenTelemetry 标准与分布式上下文传递。 自动捕获安全规则、转换、路由、Worker 执行及源站处理等环节并记录为 spans，无需额外插件或埋点。 支持基础采样率以及通过规则引擎配置的 Trace Rules，可按需对特定主机、IP 或调试标头进行 100% 追踪。 兼容 W3C traceparent 规范与 OTLP 导出，打通 Cloudflare 与第三方后端的端到端分布式追踪。 集成 MCP Server 供 AI 编码代理查询生产链路数据，并公布了将于 2026 年底生效的统一可观测性计费方案。 全链路透明化与自动化埋点 Cloudflare Traces 在开放公测中将追踪范围从 Workers 进一步延伸至整个请求流程。系统自动将自定义与托管安全规则评估、http_request_transform 转换、workers_routing 路由匹配以及缓存和回源耗时等细节记录为 span，开发者无需注入特定插件即可直观查阅请求在 Cloudflare 平台内的完整流转路径。 灵活采样策略与分布式追踪集成 用户可设置基础采样率以平衡数据量与成本，并借助与 Cloudflare 规则语言一致的 Trace Rules 针对特定 IP、路径或调试标头开启针对性全量采样。此外，该服务遵循 W3C traceparent 标准接收并向源站传递上下文，支持通过 OTLP 将链路数据导出至兼容 OpenTelemetry 的可观测性后端，实现跨技术栈的端到端调用链串联。 AI 辅助排查与统一计费模型 通过 Cloudflare Observability MCP 服务器，AI 编码代理可调用 SQL API 查询生产链路追踪数据，对比成功与失败请求并定位代码变更。在商业模式上，Cloudflare Traces 将纳入统一计费体系，按数据摄取量和留存时长计费，新定价将于 2026 年 12 月 1 日起生效，免费版提供每日 0.5 GB 摄取与 7 天保留。

Today, we’re introducing [Cloudflare Traces](https://developers.cloudflare.com/observability/traces/) in open beta, extending [automatic tracing beyond Workers](https://blog.cloudflare.com/workers-tracing-now-in-open-beta/) to the rest of the request path. In one trace, you can see supported security rules, transformations, cache decisions, routing, Worker execution, and origin handling, then continue that trace through services running on Cloudflare, at your origin, or elsewhere in your stack. This is a long-term investment in [OpenTelemetry](https://opentelemetry.io/) and in making Cloudflare the most observable part of your stack. You can now: You can [enable tracing in the Cloudflare dashboard](https://developers.cloudflare.com/observability/traces/#enable-tracing) on any domain or let your agent set up for you: `Using the Cloudflare cf CLI, configure Tracing for my zone with a 10% sampling rate and persist traces in Cloudflare. If I have multiple zones, ask me which one to use.` When our own teams investigate, we use our own internal traces, which often include thousands of spans for a single trace, generated by dozens of services and features. This lets us dig deep into every detail of a given request. We don’t think that visibility should stop at our internal systems. [Workers Tracing](https://blog.cloudflare.com/workers-tracing-now-in-open-beta/) was our first step toward exposing what happens on our platform. Last year, we launched automatic instrumentation for Worker invocations, including [outbound fetches and calls to KV, R2, D1, Durable Objects, and other Workers](https://developers.cloudflare.com/workers/observability/traces/spans-and-attributes/). It shows the work performed inside the Workers runtime without requiring tracing code for every operation. The goal of Cloudflare Traces is to bring the same level of visibility to **everyone** using Cloudflare, whether you’re building on Cloudflare or just have Cloudflare in front of an origin. You get to see how your traffic moved through our platform, and connect the dots between how you’ve configured Cloudflare, and how this influences request processing time, routing decisions, and more. A request’s path through Cloudflare can be complicated! It might pass through security rules, transformations, routing, caching, or proxied to another service entirely. Cloudflare Traces [records each supported step as a span](https://developers.cloudflare.com/observability/traces/spans/), including its timing, outcome, and relevant attributes. Instead of reconstructing the request from separate logs and configuration, you can see the request’s path through our system in one place. You can answer questions like: See when [custom or managed rules](https://developers.cloudflare.com/observability/traces/spans/#ruleset-phase-spans) evaluated the request, how long evaluation took, and the resulting action. Identify the rule responsible for a block or challenge through its span events. You can open the `http_request_transform` span to see each change, the request component it affected, and the rule responsible. You can also see where the transformation occurred relative to routing and origin handling. The `workers_routing` span shows whether a route matched, which routing type was used, and the matching route pattern. You can expand nested cache, upstream, and origin spans to see where the request spent its time. Here, you can see there was a cache miss that went to origin and spent 527ms of the 539ms getting a response. There is no special instrumentation, config, or plugins required. Once tracing is enabled for a domain, Cloudflare generates these spans automatically. This lets you extend the trace through third-party services and back again by adhering to [open standards](https://www.w3.org/TR/trace-context-1/#traceparent-header). From there, you can control which requests are traced using a baseline sampling rate and [Trace Rules](https://developers.cloudflare.com/observability/traces/configuration/#trace-rules). You can enable tracing on any domain and [set a baseline sampling rate](https://developers.cloudflare.com/observability/traces/configuration/#head-sampling) to balance visibility, data volume, and cost. You might trace 1% of requests during normal operation, giving you a continuous view of request behavior without collecting a trace for every request. [Trace Rules](https://developers.cloudflare.com/observability/traces/configuration/#trace-rules) let you keep a low baseline sampling rate while capturing complete traces for a specific investigation. If one customer reports a problem, you can trace 100% of traffic for their hostname, source IP, or identifying request header while leaving everyone else at 1%. Or during an investigation, you could trace 100% of requests carrying a temporary debug header, while leaving all other traffic at the baseline. This lets you reproduce an issue without increasing tracing across the entire domain. Trace Rules use the same [Cloudflare Rules language](https://developers.cloudflare.com/ruleset-engine/rules-language/), so you can target paths, methods, headers, IP addresses, geographies, or combinations of those properties. One of the most common requests we hear is for true distributed tracing: a single trace that follows a request into Cloudflare, through our platform, and onward through the rest of your stack. Cloudflare Traces can accept a [W3C traceparent header](https://www.w3.org/TR/trace-context-1/#traceparent-header) from an incoming request, allowing Cloudflare spans to join a trace that began before the request reached our platform. An [incoming propagation policy](https://developers.cloudflare.com/observability/traces/configuration/#incoming-trace-context) controls whether Cloudflare accepts that context. Cloudflare can also [forward a new traceparent header to your origin](https://developers.cloudflare.com/observability/traces/configuration/#forward-context-to-your-origin). Any other instrumented services can extract that context and continue the trace through APIs, databases, and services running on Cloudflare or elsewhere. To view everything as one connected trace, you can send both Cloudflare and application spans to the same OpenTelemetry-compatible backend. You can export Cloudflare spans over [OTLP](https://opentelemetry.io/docs/specs/otlp/) to a compatible observability platform, where they appear alongside telemetry from the rest of your stack. [Configure an account-level destination](https://developers.cloudflare.com/observability/export/opentelemetry/#create-a-destination), then choose which domains send traces to it. This is part of our commitment to [OpenTelemetry](https://opentelemetry.io/docs/what-is-opentelemetry/): Cloudflare represents request activity as OpenTelemetry spans and delivers them using OTLP, keeping the data portable across observability tools. When you ask a coding agent to debug a production issue, it might inspect your code and run tests, but it may not be able to see what happened to the request in production. With the [Cloudflare Observability MCP server](https://github.com/cloudflare/mcp), your agent can leverage our [SQL API](https://developers.cloudflare.com/analytics/sql-api/) to query your traces (and all of your [observability data](http://blog.cloudflare.com/one-observability-platform)!), giving it access to your investigation production telemetry. Let your agent find the right requests, comparing failed traces with successful ones, and identifying where their spans diverge. Since the agent can also inspect your repository, it can connect those findings to the relevant code, narrow down what needs to change, and help put up a fix for you to review. Cloudflare Traces will be a part of the [unified Cloudflare Observability pricing model](https://developers.cloudflare.com/observability/pricing/). Instead of charging by the number of spans/events, pricing is based on how much observability data you ingest and how long you retain it. New pricing will take effect across Cloudflare Tracing (and Workers Tracing!) starting December 1, 2026. | Plan | Included Usage | Retention | Additional Usage | |---|---|---|---| | Free | 0.5 GB of ingestion per day | 7 Days | Not available | | Paid and Enterprise | 50 GB of ingestion 10 GB-month of storage per billing cycle | Up to 1 year  (coming soon) | $0.25 per GB ingested $0.10 per GB-month stored | Following the open beta, we plan to launch: Follow the [Cloudflare Traces documentation](https://developers.cloudflare.com/observability/traces/) to trace your first request and tune sampling with Trace Rules. Cloudflare Traces is available in open beta from the dashboard, through the API, or with Terraform, with support for exporting to an OTLP destination.