Configure frontend-backend linking for web frontends

Latest Dynatrace
How-to guide
Published Apr 30, 2026

For web frontends, the New RUM Experience supports two frontend-backend linking approaches:

The W3C trace context links XHR and Fetch requests to distributed traces captured on backends instrumented with OneAgent or OpenTelemetry.
The Server-Timing header links requests for the HTML document and its included resources to distributed traces captured on backends instrumented with one of the OneAgent technologies listed in Technology support - Real User Monitoring - Web servers and applications.

This page describes the settings available for both approaches. For details on each approach, see Frontend-backend linking.

Control the addition of the W3C trace context

By default, the W3C trace context is added to same-origin XHR and Fetch requests. Optionally, you can also configure its addition for cross-origin requests.

Add the W3C trace context to cross-origin requests

Prepare your endpoints first

Adding the W3C trace context to cross-origin requests requires correctly configured CORS handling on the receiving endpoints. If the endpoints aren't prepared to accept the traceparent and tracestate headers, the affected requests will fail with CORS errors and parts of your web application may break. You are responsible for your endpoint configuration; validate the setup in a pre-production environment before turning on this option.

To link cross-origin XHR and Fetch requests with distributed traces from a backend instrumented with OneAgent or OpenTelemetry using the W3C trace context, complete the following steps.

Prepare your endpoints to accept the trace context headers

Configure the cross-origin URL pattern in Dynatrace

Prepare your endpoints to accept the trace context headers

When the traceparent and tracestate headers are added to a cross-origin XHR or Fetch request, the browser issues a CORS preflight request—an OPTIONS request—before the actual request. The endpoints that handle your cross-origin requests must respond with the appropriate CORS headers on both the preflight response and the response to the actual request. Otherwise, the request fails with a CORS error.

The response to the preflight (OPTIONS) request must include the following headers:

Access-Control-Allow-Origin—identifies the origin that is allowed to access the resource. Either a specific origin matching the request's Origin header, or * for any origin.
Access-Control-Allow-Methods—lists the HTTP methods allowed for cross-origin requests; must include the method of the actual request (for example, GET or POST).
Access-Control-Allow-Headers—lists the request headers allowed for cross-origin requests; must include traceparent and tracestate.

The response to the actual request must include:

Access-Control-Allow-Origin—with the same value rules as for the preflight response.

Configure the cross-origin URL pattern in Dynatrace

Go to Experience Vitals > Overview.
Select Web to view all web frontends.
Select the frontend you want to configure.
On the Settings tab, select Frontend-backend linking.
Under Cross-origin URL pattern, enter a regular expression that matches the URLs of the requested resources.

The RUM JavaScript tests the regular expression against the URL using RegExp.prototype.test(). The regular expression does not need to match the full URL, but only a substring of it. Matching is case-insensitive.

Avoid inefficient regular expressions

Inefficient regular expressions can cause performance issues in your application, including browser freezes lasting several seconds. For better performance, write expressions that match a URL substring rather than the entire URL. This is especially relevant for long URLs.

Regex tester sites

When composing your regular expression using a site like Regex101, select the following options:

The flavor ECMAScript (JavaScript)
The delimiter "
The Case insensitive match flag

Deactivate the addition of the W3C trace context

If the addition of the W3C trace context causes issues in your environment, you can turn it off temporarily. XHR and Fetch requests can still be linked via the Server-Timing header when the backend is instrumented with one of the OneAgent technologies listed in Technology support - Real User Monitoring - Web servers and applications. However, we don't recommend leaving trace context propagation turned off, because it provides more robust and precise linking.

To turn off the addition of the trace context

Go to Experience Vitals > Overview.
Select Web to view all web frontends.
Select the frontend you want to configure.
On the Settings tab, select Frontend-backend linking.
Turn off Enable frontend-backend linking via W3C trace context.

Control the addition of the Server-Timing and Timing-Allow-Origin headers in cross-origin scenarios

For cross-origin requests, the RUM JavaScript can access the Server-Timing header value only if the response includes a Timing-Allow-Origin header that permits the request's origin. To grant this access, OneAgent automatically adds a Timing-Allow-Origin header to your web application's response if your application doesn't already set one. The Timing-Allow-Origin header controls access not only to the Server-Timing header value, but also to detailed resource timing data. By default, the added header uses a wildcard (*) value.

If this permissive default doesn't meet your requirements, you can define rules that restrict which origins receive the two headers. When a rule matches, the Timing-Allow-Origin header contains the origin from the request's Origin header instead of a wildcard.

To add a rule

Go to Settings > Collect and capture > Real User Monitoring > Frontend > Advanced correlation.
Select Add item.
Under Matcher, select contains, starts with, ends with, or equals.
Under Pattern, enter a pattern that identifies the origin or origins the rule should accept. An origin consists of the protocol, host, and port; default ports are omitted.

Rules defined in Advanced correlation apply to your entire environment. As soon as you add the first rule, requests from any origin that doesn't match a rule no longer receive the Server-Timing and Timing-Allow-Origin headers in the response. As a result, frontend-backend linking becomes unavailable for these requests, except for XHR and Fetch requests that carry the W3C trace context.