Cloudflare Traces brings end-to-end request visibility to open beta

Cloudflare has launched Cloudflare Traces in open beta, extending automatic request tracing beyond its Workers runtime to cover the entire request path. Announced on October 2, 2026, this feature allows developers to visualize how traffic moves through security rules, caching layers, and routing logic before reaching their origin servers.

The new tool aims to provide the same level of internal visibility that Cloudflare engineers use for debugging, now available to all customers. By adhering to OpenTelemetry standards, it enables seamless integration with existing observability stacks while offering native inspection tools within the Cloudflare dashboard.

What happened

Cloudflare Traces captures supported platform operations as spans in a single request-level timeline without requiring additional instrumentation code. When enabled for a domain, the system automatically records steps such as security rule evaluations, URL transformations, cache decisions, and Worker execution. This eliminates the need to reconstruct request flows from disparate logs and configuration files.

Users can view these traces directly in the Cloudflare dashboard or export them via the Open Telemetry Protocol (OTLP) to third-party observability platforms. The system supports W3C traceparent headers, allowing trace context to propagate from upstream services into Cloudflare and onward to origin systems. This creates a continuous view of a request’s journey across distributed environments.

To manage data volume and cost, Cloudflare introduces Trace Rules alongside a baseline sampling rate. Administrators can set a low default sampling percentage, such as 1%, for general traffic. They can then override this rate for specific investigations by targeting traffic based on hostname, source IP, headers, or geography. This approach allows teams to capture 100% of problematic requests during an incident without overwhelming their storage limits.

Key details

• Automatic instrumentation: No plugins or config changes are needed; tracing begins once enabled for a domain.
• OpenTelemetry compatibility: Spans are exported via OTLP, ensuring portability across different observability backends.
• Context propagation: Supports accepting and forwarding W3C traceparent headers for end-to-end distributed tracing.
• Configurable sampling: Baseline rates can be adjusted, and Trace Rules allow targeted high-volume tracing for specific issues.
• Dashboard integration: Request timelines and span details are viewable directly within the Cloudflare interface.
• Agent support: The Cloudflare Observability MCP server allows coding agents to query traces via SQL API for automated debugging.

Background

Distributed tracing is a method used to monitor and troubleshoot applications that are split across multiple services or infrastructure components. As modern software architectures become more complex, a single user request may touch dozens of systems, making it difficult to identify where delays or errors occur. Traditional logging often fails to connect these events chronologically.

OpenTelemetry is an open-source framework that provides standardized APIs and tools for collecting telemetry data, including traces, metrics, and logs. By adopting this standard, Cloudflare ensures that its tracing data can be easily consumed by popular monitoring tools like Jaeger, Zipkin, or commercial platforms. This avoids vendor lock-in and allows engineering teams to maintain a unified view of their entire stack.

Why it matters

For teams running self-hosted software behind a content delivery network or proxy, understanding the boundary between the provider’s infrastructure and their own servers is critical. Issues such as unexpected cache misses, aggressive security blocks, or URL rewriting errors can be notoriously difficult to debug without visibility into the proxy layer. Cloudflare Traces exposes these internal decisions, helping developers distinguish between application bugs and platform configuration issues.

The ability to export data via OTLP means that organizations do not need to fragment their monitoring strategy. They can keep their existing observability pipeline while gaining deeper insights into the edge layer. This is particularly valuable for DevOps engineers who need to correlate edge performance metrics with backend application logs to resolve production incidents faster.

Furthermore, the granular control over sampling helps manage costs associated with high-traffic sites. Instead of paying for every single span generated, teams can focus their budget on capturing relevant data during outages or for specific customer segments. This makes advanced observability accessible to mid-sized companies that might otherwise find full-scale distributed tracing prohibitively expensive.

What you can do

• Enable Cloudflare Traces for a specific domain via the dashboard or Terraform to start generating spans automatically.
• Set a baseline sampling rate, such as 1%, to balance visibility with data ingestion costs during normal operations.
• Create Trace Rules to increase sampling to 100% for specific paths, headers, or IP addresses when investigating reported issues.
• Configure an OTLP endpoint in your account settings to export spans to your preferred external observability platform.
• Use the Cloudflare dashboard to inspect individual request timelines, focusing on cache status and security rule actions.
• Integrate the Cloudflare Observability MCP server if you use AI coding agents to help them query production telemetry for debugging.