A customer reports that a page fails. The application log shows nothing. The request may have been blocked, rewritten or served from cache before it reached the application you are checking.

Cloudflare's 2 October 2026 Traces announcement introduces an open beta that follows supported operations through the platform's request path. These can include security rules, transformations, cache decisions, routing, Workers and origin handling.

Start with a specific request

For a hosting team, a useful investigation begins with the URL, time, observed result and available request identifiers. Record what the customer expected and which browser or network was involved.

A vague report that the site is broken makes it harder to choose a representative request. Ask whether the problem affects a particular route, logged-in account or action.

Then reproduce it through the normal test process, avoiding unnecessary live orders or changes to customer data. Compare a failing request with a successful one under similar conditions.

Look for the step that changes the outcome

Cloudflare describes trace spans for supported rule evaluations, URL changes, routing and cache or origin work. The dashboard can show timing and outcomes along that path.

For example, a request may match an unexpected rule before the origin is contacted. Another may reach the origin successfully but wait there for most of its total duration.

Those observations give you a narrower next question. Review the responsible rule or the corresponding origin request, then check whether a change produces the intended result.

Choose sampling deliberately

The beta supports a baseline sampling rate and Trace Rules to select matching traffic. It also supports W3C trace-context propagation and export to compatible OpenTelemetry destinations.

Our suggested approach is to begin with the route you are investigating and a controlled level of collection. Review the volume, access and cost under your current account arrangements before expanding it.

Remember that a missing trace may reflect sampling rather than a request that never happened. Keep other request evidence available while you investigate.

Connect the edge result to your application

A platform trace can explain the supported steps it sees. To follow later work in your own application, check the application's instrumentation and how context reaches downstream services.

Keep identifiers consistent enough to match an edge request with its origin log entry. Review what appears in exported telemetry so credentials and unnecessary customer details do not become troubleshooting data.

Give the team a short procedure for a common problem: locate the request, inspect the relevant step, match the origin record and retest the change. That makes the feature useful beyond the person who first configured it.

The beta is worth assessing against a real support question. Pick one request your current logs struggle to explain and see whether the trace provides the missing evidence.

Reporting checked on 13 October 2026. Feature scope follows Cloudflare's open beta announcement.