Cloudflare Traces Pricing Makes Proxy-Layer Visibility a Capacity Decision

Cloudflare has moved Traces into open beta, extending OpenTelemetry spans beyond Worker execution to cover security rules, transformations, cache, routing and origin handling ¹. The same announcement sets a pricing shift for December 1: billing will move to ingestion and retention volume, though Cloudflare has not published rates or billing mechanics ¹.

For platform teams running AI applications on Cloudflare, that combination forces an unusual sequence: deciding whether proxy-layer visibility is worth paying for by volume before the commercial terms exist.

What changed in Cloudflare OpenTelemetry tracing?

The core change is scope. Traces now captures more than Worker execution. Cloudflare lists security rules, transformations, cache, routing and origin handling as additional span sources, alongside Workers ¹.

That matters because a request crosses several control points before it reaches application code. A security rule can block it. A transformation can rewrite it. Cache can serve it. Routing can send it somewhere the application never intended. Worker-only traces showed none of those decisions.

Traces also accepts and forwards W3C traceparent headers ¹, so trace context can travel from the incoming request through Cloudflare's proxy path into downstream services without a custom propagation layer. One trace ID can tie the edge decision, the Worker execution and the origin response together.

What the announcement omits matters just as much: there is no published list of attributes, events or status fields for the security, cache or routing spans ¹. Teams should check the actual span content before assuming it replaces logs or metrics for incident diagnosis.

Which teams benefit most from proxy-layer tracing for AI applications?

The clearest beneficiaries are platform teams responsible for both edge behavior and application operations. They are the only group that needs one trace across security rules, transformations, cache, routing, origin handling and Workers at once ¹.

For AI application tracing specifically, the value is request-path diagnosis. A failed inference request can die at several boundaries: an edge security rule may reject it, a cache may return a stale or wrong response, routing may send it to the wrong model backend, or the Worker may fail before reaching the origin. A trace spanning those stages tells the team which boundary to investigate, instead of starting from the application error alone.

This is an operational use case inferred from the stages Cloudflare says Traces covers, not a measured result from a specific workload ¹. Teams that already send inference traffic through an enterprise AI gateway will also want to decide which layer owns which part of the request record, so the same event isn't traced, stored and paid for twice.

The contrast case is a team whose incidents live almost entirely inside application code. If proxy behavior rarely causes failures, the new spans add little beyond existing application tracing. The source offers no workload thresholds or comparative data to separate the two cases ¹.

Split the adoption question in two. Does proxy-layer tracing solve a diagnostic problem the team has today? Does the resulting ingestion and retention volume fit the budget? Answering only the first risks building a dependency the team can't afford to run at full fidelity.

How does targeted sampling change Cloudflare Workers observability?

Trace Rules support targeted sampling, so teams can choose where to collect more complete traces rather than treating every request identically ¹.

The sampling policy is where the design work happens. Whether rules can target specific routes, request classes, error conditions or providers is a question to validate, not a promised feature. The source confirms targeted sampling exists but does not describe the configuration model ¹.

The trade-off is structural. Broader sampling raises the odds of catching rare proxy behavior but increases ingestion and, potentially, retention volume. Narrower sampling controls cost but can miss the low-frequency failures that justify the tool in the first place. The cost side follows from the announced volume-based pricing; the trade-off itself is analysis ¹.

A defensible design preserves traces for the requests a team can't afford to lose: error paths, unusual routing outcomes and origin failures, sampled more aggressively than successful cache hits. Whether Trace Rules can express that distinction is still open.

The same question of what evidence to keep, and for how long, shows up in agent deployments too. See AI Agent Governance: What Evidence Is Enough Before an Agent Can Take Action? for that side of the problem.

What should teams evaluate in Cloudflare Traces pricing?

The known pricing change is narrow: Cloudflare says billing is moving to ingestion and retention volume from December 1 ¹. The source does not state the year, rates, retention periods or pricing tiers.

That gap makes the questions more useful than any answer available today. Ask Cloudflare how billable ingestion is calculated: all generated spans, sampled spans, retained spans, or something else. The source doesn't specify the formula ¹.

Then measure rather than estimate. During the beta, a team can compare the volume its own traffic generates under different sampling rules against the diagnostic value of the spans. Trace spend is one line item among several in an AI stack, and model usage is another; on that side, pricing in Yelno is shown as a final price on every response, which makes the two budgets easier to compare.