This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
Accept
Reject
Preferences
FAQ
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 
New Article

RUM data is assigned to a different application than expected

MargitM
Dynatrace Contributor
Dynatrace Contributor

‎16 Sep 2025 02:17 PM - edited ‎17 Sep 2025 07:47 AM

 

The problem

 

When using automatic RUM injection, the application to which RUM data is assigned is determined by application detection rules. Occasionally, however, the captured RUM data may be mapped to a different application than expected.

This guide is designed to help you systematically analyze such issues. For best results, we recommend working through the steps in sequence.

 

How application detection rules are applied

 

To effectively troubleshoot application detection issues, it's essential to understand how application detection rules are applied. Please read How does Dynatrace apply your application detection rules? before continuing—this knowledge is crucial for following the guide.

When the New Real User Monitoring Experience is enabled for an application, a portion of the beacons include the application ID in the query string parameter ai instead of app.

 

Double-check your application detection rules

 

Before diving into the triage section, take a moment to review your application detection rules to ensure they’re configured correctly.

RUM application detection uses the URL structure scheme://host:port/path?query, where the query string is optional and default ports (80 for HTTP and 443 for HTTPS) are omitted. Watch out for these common pitfalls:

  • If you're using a URL matcher such as URL contains or URL ends with, ensure that the pattern does not include a fragment identifier (e.g., #section). Fragment identifiers are only used by the browser and are not part of the HTTP request.
  • Avoid using patterns that include the scheme https:// unless you're certain that HTTPS isn't terminated before reaching the first instrumented tier.
  • When using domain matchers such as Domain (host) contains or Domain (host) ends with, ensure the pattern includes only the host part of the URL or a portion of it.

To find out which application detection rule applies to a specific URL, use the application detection rule checker under Settings → Web and mobile monitoring → Application detection → Check your existing detection rules. Keep in mind that this tool doesn’t account for factors like URL rewriting—those will be addressed later in this guide.

 

Triage

 

The following analysis steps will help you determine which category of common issues—described later in this article—may be relevant to your situation.

 

Find an affected load action

 

Start by identifying a load action that is mapped to the wrong application. If you're investigating an XHR or custom action that appears in the wrong application, look for the corresponding load action on the same page.

To do this, check the session details page to see where the user navigated before the XHR or custom action was triggered.

➡️ If you can only find affected XHR actions and no corresponding load action is available, refer to Application detected for XHR actions does not reflect recent application detection rule changes.

 

Find the trace for the HTML document request

 

To navigate from the load action to the trace for the HTML document request:

  1. Click on the document request within the load action.
  2. Click the View trace button.

app_detection_find_trace.png

➡️ If none of the affected load actions includes a trace link for the document request, refer to Caching issues after a change of the application detection rules.

 

Identify the URL reaching the OneAgent

 

Once you've located the relevant trace, click the topmost entry. This will open a detailed view on the right-hand side, where you can find the host and the URL path and query listed as separate fields.

app_detection_find_trace_URL.png

Next, compare this URL with the one associated with the load action. Look for any discrepancies between the two.

➡️ If you notice differences, refer to Issues caused by URL rewriting on an uninstrumented component.

 

Find out which application detection rule was applied to a request

 

The view on the right also shows the application detection rule that was used. By clicking on it, you can jump directly to its configuration:

app_detection_find_rule.png

➡️ If this view shows the rule you expect to match—even though the RUM data is assigned to an unexpected application—check the section x-dynatrace-application header is not propagated.

 

Common issues

 

This section lists frequently encountered app detection problems and their solutions. For best results, start with the Triage section above to identify which issue applies to your case, then refer to the relevant subsection below.

 

Issues caused by URL rewriting on an uninstrumented component

 

As explained in How does Dynatrace apply your application detection rules?, your application detection rules are evaluated by OneAgent on the first instrumented tier of your application. However, there may be an uninstrumented component, such as a reverse proxy or a load balancer, between the browser and the first instrumented tier of your application that rewrites the URL. As a result, the URL used for application detection may differ from the URL that was originally requested by the browser.

Uninstrumented component sets the original host in a header not included in the default host name determination configuration

OneAgent can recover the original host name requested by the browser by evaluating specific request headers, see What can I do if an uninstrumented component rewrites parts of the URL?.

You can view and configure these headers under Settings → Web and mobile monitoring → Host name determination. The list is evaluated in order of priority, starting from the top. It includes several default entries, with the de facto standard header X-Forwarded-Host having the highest priority by default.

There are cases where you may need to add additional entries to this list:

  • The component uses the Forwarded header: This standardized replacement for the X-Forwarded-* headers includes multiple fields. It is part of the default host name determination list in environments created since Dynatrace version 1.267. Since OneAgents have long supported parsing this header, you can manually add it to the list in older environments if needed.
  • The component uses a proprietary header: Any header used for host name determination—except for the Forwarded header—must follow the format of the Host header: <host> for default ports, or <host>:<port> otherwise. A comma-separated list of such entries is also supported, with the assumption that the first entry represents the original host name.

When adding a new entry, place it above the Host header entry, which is present in every HTTP/1.1 request.

If you want to check whether a specific request header reaches OneAgent, you can add it as a request attribute.

⚠️ Make sure your host name determination configuration does not include the Referer header, as it is not suitable for this purpose and will lead to unpredictable results.

Uninstrumented component does not set a header with the original host

If the uninstrumented component does not set a header containing the original host, there are two possible approaches:

  • Preferred: Configure the component (or the one closest to the browser, if multiple are involved) to set a header such as X-Forwarded-Host.
  • Alternative: Use the internal host name in the application detection rule. Note: The automatic determination of the cookie domain depends on the host detection result. If only the internal host name is available to OneAgent, the cookie domain may need to be configured manually.

Application detection rule uses a URL path segment that is removed by URL rewriting

In some cases, an application detection rule may rely on a part of the URL path that gets removed during URL rewriting by an uninstrumented component. Unlike the host portion of the URL, there is no built-in mechanism to recover the original path, since most components do not forward this information via headers.

If this applies to your setup, you’ll need to adjust the application detection rule to use a different part of the URL that remains intact after rewriting.

 

x-dynatrace-application header is not propagated

 

In multi-tier applications, the application is detected on the first instrumented tier—usually a proxy—while the RUM JavaScript is injected on the tier that generates the HTML response. On the typical proxy technologies (Apache, Nginx, IIS), OneAgent sets the x-dynatrace-application header on the request to propagate the detected application from tier to tier.

If the topmost node in the trace shows the expected application, but the captured RUM data is assigned to a different application, it's likely that your application spans at least two tiers and the x-dynatrace-application header is not being propagated between them.

Scenario 1: Apache, Nginx, or IIS on the first instrumented tier

If the first instrumented tier is Apache, Nginx, or IIS, OneAgent sets the x-dynatrace-application header there, but your infrastructure removes it before it reaches the injecting tier. To verify, you can add the header as a request attribute.

As a solution, please review the Firewall constraints for RUM and configure your infrastructure accordingly.

Scenario 2: Java, Node.js, or ASP.NET Core on the first instrumented tier

If the first instrumented tier is a Java, Node.js, or ASP.NET Core process, the x-dynatrace-application header is not set, since these technologies are not typically used as proxies. The following sections describe three different workarounds and the scenarios where they are applicable.

Workaround 1: Disabling RUM on all tiers except for the first one

With Node.js or ASP.NET Core on the first tier, disabling RUM on all other tiers is a viable workaround. With this configuration, the OneAgent on the first tier will take over injection.

With a servlet-based Java application on the first tier, this workaround can only work if the HTML reaches the OneAgent that instruments it in an uncompressed form.

With Netty on the first tier, this workaround is not applicable, since RUM injection is not supported for Netty.

⚠️ Do not use this workaround if you'd need to disable RUM on a tier that acts as the entry point for other requests or another application.

Workaround 2: Using domain-based application detection rules

Basing your application detection rule solely on the domain ensures consistent application detection across tiers, provided the component on the first tier propagates the host name using a header such as X-Forwarded-Host.

If host name propagation hasn't been configured yet, adjust your component accordingly and ensure that the relevant header appears above the Host header in the list under Settings → Web and mobile monitoring → Host name determination.

To verify that the header reaches the injecting tier, you can add it as a request attribute.

Workaround 3: Defining application detection rules based on the the internal URL

If neither of the previous approaches is applicable, you can define application detection rules based on the internal URL observed by OneAgent on the injecting tier. To identify the internal URL, inspect the trace.

When using this setup, it's important to ensure the cookie domain—normally also derived from the x-dynatrace-application header—is correctly configured:

 

Caching issues after a change of the application detection rules

 

Caching can delay the immediate effectiveness of application detection rule changes in the following two primary scenarios.

Requests are handled by a CDN or caching proxy

When HTML is served through a CDN or caching proxy, OneAgent can inject the RUM JavaScript only if the HTML is fetched from the instrumented origin server—typically after the cached version has been evicted.

If you've updated your application detection rules in this setup, the changes won't take effect until OneAgent is able to inject the RUM JavaScript again with an updated app parameter in the configuration.

If you don't want to wait until the CDN edge servers serve the freshly injected page, manually clear the CDN cache to force a request to the origin server.

Long expiration times or missing caching policy

Check the caching headers on the response for the HTML document if you observe the following:

  • You cannot reproduce the issue with a cleared cache.
  • The affected load actions do not have a drilldown to a trace for the request to the HTML document.

The following response headers control how long a resource may be cached before it expires:

  • Cache-Control: max-age: Defines the cache duration in seconds, e.g. Cache-Control: max-age=2592000
  • Expires: Specifies an absolute expiration date in HTTP date format, e.g. Expires: Sun, 01 Nov 2020 06:47:04 GMT

If either of these headers is present, the cached HTML may continue to be served with the previously injected app parameter until the cache expires. As a result, changes to application detection rules won’t take effect immediately.

If an application does not specify an explicit expiration time, then this does not mean that the page may not be cached. The cache may use the page without revalidation as long as it deems appropriate, unless the response contains directives that prevent this, for example, Cache-Control: no-store.

In these situations, the only resolution is to wait until the outdated HTML document is evicted from all caches and OneAgent can inject the updated configuration.

To avoid similar delays in the future, consider adjusting your caching strategy. Use short expiration times, or rely on validation-based caching using the ETag or Last-Modified headers.

 

Application detected for XHR actions does not reflect recent application detection rule changes

 

This scenario applies if you observe the following:

  • Load actions are correctly assigned to the expected application.
  • However, XHR actions from some users continue to appear under a different application— the one where the page was assigned before a recent change to the application detection rules.
  • It is not possible to reproduce the issue with a cleared browser cache.

This behavior usually appears in single-page applications (SPAs). Instead of loading a new HTML page from the server, SPAs dynamically update the current page using XHRs. If the HTML was initially loaded before the application detection rules were updated, the app parameter embedded in the page may still reflect the previous configuration. As a result, XHR actions are mapped to the outdated application.

This situation resolves automatically once the user refreshes the page or the application triggers a full reload. Until then, the outdated mapping will persist.

 

What's Next?

 

If you've completed the troubleshooting steps above but still haven't identified the root cause, please contact Dynatrace via the in-product chat or by creating a support ticket.

To help our support team investigate efficiently, include the following information:

  • A HAR file, or, preferably, a Fiddler session capturing the full scenario.
  • A link to the affected user session.
  • A brief summary of the troubleshooting steps you've already completed.

Providing this information upfront will help accelerate the resolution process.

Version history
Last update:
‎17 Sep 2025 07:47 AM
Updated by:
Dynatrace Contributor