Why don't I see my applications or monitoring data?

This page explains what to do when Real User Monitoring (RUM) isn't working in your environment.

Before performing any troubleshooting, try checking the health check page for your application.

General troubleshooting

To confirm that your application web frontend process is monitored

From the Dynatrace menu, go to Settings > Monitoring > Monitoring overview.
Switch to the Process groups tab, and search for the required process group. All monitored processes are listed on this page.

If RUM data is ending up in the wrong application, make sure that you've correctly configured the application detection rules. For details, see Check application detection rules and Define applications for Real User Monitoring | Application detection rules approach.

If you don't see any of your applications or RUM data in the Dynatrace web UI, start by confirming that there's traffic in your web frontend processes (web server, Java, Node.js, and more). To do this, interact with one of your application pages to generate some traffic.

Once you're certain that your web frontend processes have traffic on them, check the following to determine the cause of the problem:

See the expandable sections below for details on confirming these points.

In rare circumstances, the RUM JavaScript injected into your application pages can have an adverse impact on the application functionality. For this reason, following installation of OneAgent, confirm that your application pages still render properly. If some of your application pages appear to be corrupted, disable RUM and contact a Dynatrace product expert via live chat within your Dynatrace environment.

The first thing to do in verifying that RUM has been set up correctly is to search for the Dynatrace RUM JavaScript in your application HTML.

Load one of your pages, inspect its source in the web browser, and make sure that the <HEAD> element contains a reference to the RUM JavaScript. If you're not able to locate the RUM JavaScript, make sure that you're using well-formed HTML with opening and closing tags for <HTML> and <HEAD>. For more details on whether your HTML fulfills the requirements for auto injection, visit RUM JavaScript injection.

For standard OneAgent installations (automatic RUM JavaScript injection)

Depending on the injection format you have selected, different formats of the RUM JavaScript look differently, but what they all have in common is the data-dtconfig attribute.

Search for a script that contains the data-dtconfig attribute in the tag.

1<script type="text/javascript" src="/ruxitagentjs_[...]_[...].js" data-dtconfig="[...]"></script>

RUM troubleshooting - example of the injected RUM JavaScript

For agentless monitoring (no OneAgent, no automatic injection)

If you're using the Code snippet, Inline code, or OneAgent JavaScript tag injection format, search for a script that contains the data-dtconfig attribute in the tag.

1<script type="text/javascript" src="https://js-cdn.dynatrace.com/jstag/[...]/[...]/[...]_complete.js"></script>

In the example above, [...] indicates a variable URL element, such as an application ID or a configuration parameter.

If you don't see the RUM JavaScript automatically injected by OneAgent, it's probably because of one of the following reasons:

Dynatrace OneAgent could not identify the content as HTML or canceled the injection attempt due to an invalid HTML structure or incorrect encodings. See RUM JavaScript injection to learn how OneAgent injects the RUM JavaScript into your application.
The request maps to a different application than expected because application detection was set up incorrectly. Either the pattern is incorrect, or the associated web servers operate behind proxies or other components that are rewriting the URL. For details, see What can I do if an uninstrumented component rewrites parts of the URL?.
The application that is detected by OneAgent on the first instrumented tier is not propagated to subsequent OneAgents because the x-dynatrace-application header is removed by a firewall or proxy.
You have defined exclusion rules for browsers, robots, and spiders.

The Dynatrace RUM JavaScript for your application is downloaded along with all other web page resources. You can confirm that the download was successful using the development tools available in your browser (for example, DevTools in Chrome) or with a tool like Fiddler.

Open your preferred development tool, go to the Network or Net section, and load your application page in a browser. In the Network section, you should see the list of network operations and their statuses. Look for the following:

Responses that contain the RUM JavaScript.
Responses must have 200 OK or 304 Not Modified status. The script file may come from cache.
Existence of the JavaScript object dT_.
To do this, go to your browser developer console, type dT_, and use Enter. As a result, an object should be returned.

See examples below for Google Chrome that show server responses containing the correct script content:

RUM troubleshooting - server responses containing the correct script content

There are a few reasons why the RUM JavaScript may not be downloadable.

For agentless monitoring
- The RUM JavaScript is incorrect.
- Content Security Policy rules prevent loading of the RUM JavaScript.
- The RUM JavaScript host https://js-cdn.dynatrace.com isn't reachable for client browsers due to firewall rules or proxy server configuration. Connections to and from the host must be allowed.
For automatic injection on web servers
- Rules on firewalls, load balancers, or proxies aren't configured to allow RUM JavaScript download.
For automatic injection on Java application servers
- Root application doesn't exist. The RUM JavaScript is usually loaded from the web server root path (.../ruxitagentjs_...).
- Your Java application server serves static content in a way that doesn't use the servlet stack. In such cases, the RUM JavaScript can't be downloaded.

To resolve a JavaScript download issue caused by a missing root application:

In the Dynatrace menu, go to Web.
Select the application that you want to configure.
In the upper-right corner of the application overview page, select More (…) > Edit.
From the application settings, select Capturing > Advanced setup.

Scroll down to the JavaScript library section.
Specify the source path for placement of your application JavaScript library file in the Specify location for JavaScript library file field. This path needs to point to a location where the RUM JavaScript is accessible (for example, a valid servlet path).

The RUM JavaScript reports back data via XHR or CORS POST requests. You can view these requests among network operations using browser development tools.

For agentless monitoring
CORS requests to the Dynatrace infrastructure should be visible. Look for the following:

URL pattern: http(s)://[...].live.dynatrace.com/bf
Responses must have 200 OK status, and response content must start with "OK".

Agentless monitoring - CORS requests to the Dynatrace

For automatic injection
XHR requests back to the server-side should be visible. Look for the following:

URL is relative to the current page location and begins with rb_
Responses must have 200 OK status and response content must start with "OK".

Automatic injection - XHR requests

If the response content starts with "FL", the beacon was rejected and not forwarded to the server. The response contains additional information about the problem. One possible root cause is that Dynatrace throttled the capture rate of your application.

Possible reasons for failure

The reasons for this are similar to the reasons why the RUM JavaScript may not be downloaded:

Rules on firewalls, load balancers, or proxies may need to be adapted.
Content security policy settings may need to be adapted.
Java application server setup may need to be adapted.
For agentless monitoring, your browser may not support CORS requests. Data can be reported only via browsers that support CORS.

Content that is delivered as XHTML (content type application/xhtml+xml) can cause troubles with the injected RUM JavaScript. No CDATA comments (//<![CDATA['...) are injected as XHTML has been deprecated, but this can still cause browsers to not execute the RUM JavaScript. You must manually add the proper CDATA comments for the RUM JavaScript to execute properly.

RUM correlation requires the dtCookie and dtPC cookies to be on web requests in order to link them to user actions. However, because dtCookie is part of the beacon and because the RUM JavaScript sets and modifies these cookies, they don't support the HttpOnly flag. See Cookies for complete details.

To confirm that the monitor signal is correctly passing through your infrastructure to OneAgent, you must call the URL form <your hostname>/rb_<Your external Environment ID>?$.

To get your environment's URL for the monitor-signal check

Open your browser's developer tools, and look for an XHR Post request that begins with rb_<ID>, for example, https://www.mydomain.com/rb_bf24977vwq.
Copy the URL of this request, and append the ?type=check query string, for example, https://www.mydomain.com/rb_bf24977vwq?type=check.
Use Enter to execute the URL in your browser.

You should receive a response with status 200 and some text like "state=ok&agentType=nginx&agentVersion=1.121.170.20170703-101146". As long as the string state=ok appears (along with other text and HTTP status), then you know that the beacon signal is passing through your servers, and you should be receiving RUM data.

If these suggestions don't resolve your issue, please contact a Dynatrace product expert via live chat within your Dynatrace environment.

If your application isn't working under this scenario, see if the application works with the RUM JavaScript disabled. To do this, block the request using either Fiddler or Chrome DevTools.

In Chrome DevTools, go to the Network tab.
Select More (…) > Network request blocking.
Select Enable network request blocking, and then enter part of the URL of the RUM JavaScript, for example, ruxitagent. Note that this does not work for the inlined RUM JavaScript.

If the application doesn't work with the RUM JavaScript disabled, the problem is likely in the application or caused by OneAgent. However, if the application works after disabling the RUM JavaScript, re-enable the RUM JavaScript but disable all modules. Try enabling modules one at a time until the application does not work anymore. Use this information when contacting Dynatrace product experts, as it helps to narrow down the problem to a certain module.

New user sessions aren't reported in real time. There is a delay of 5–6 minutes from the moment a new user session begins until the user session is reflected in charts and other analytical views in the Dynatrace web UI. This delay results in a slight drop in the number of user sessions that are recorded at the end of each time interval during which new user sessions are started.

We ended support for Internet Explorer 7–10 starting with RUM JavaScript version 1.265. As a result, the RUM JavaScript can't initialize on these browsers and, therefore, can't send any RUM data to Dynatrace.

However, it's possible to choose a version of the RUM JavaScript that is compatible with Internet Explorer 7–10. For more information, see RUM JavaScript for Internet Explorer 7–10.

RUM JavaScript version 1.263 is the last version that is compatible with Internet Explorer 7–10. This version is provided as-is and will only receive security updates if necessary; there won't be any other updates for this version.

If your application might be accessed via Internet Explorer 7–10

Use RUM JavaScript version 1.263 or earlier, as later versions don't support Internet Explorer 7–10.

If you opt for RUM JavaScript version 1.265+, the RUM JavaScript won't initialize at all, and the browser console will show a message stating that the RUM JavaScript is disabled or/and that the browser can't parse the RUM JavaScript.

If your application might be accessed via Internet Explorer 11

Even though the RUM JavaScript is supported for Internet Explorer 11, it's not supported for Compatibility View in Internet Explorer 11.

If your application might be viewed via Internet Explorer 11 with Compatibility View enabled, use RUM JavaScript version 1.263 or earlier.

If you choose RUM JavaScript version 1.265+, the RUM JavaScript won't initialize at all, and the browser console will display the following message:

1Unsupported Internet Explorer version detected. Only version 11 (without Compatibility View) is supported!

If user action data is missing from your monitored web application, you can perform the following checks in Google Chrome with Chrome DevTools open, and then use Chrome DevTools to verify that certain data exists to see if user action data is captured properly. Select F12 to open Chrome DevTools in Chrome.

Make sure the user action triggers network traffic. Open the Network tab in Chrome DevTools, and then clear all requests. Perform the action you would like to check and inspect the action's network traffic. To do this, check the Type column in the Network tab. If there are no xhr or fetch type requests, this is not an action and the RUM JavaScript won't report it. Images and CSS information don't count as xhr or fetch and won't cause an action to be generated. If you see no xhr or fetch requests, use the JavaScript API to manually monitor this action.
Make sure the action does not use setTimeout(async). Perform the action you would like to check and use Chrome DevTools to make sure there is an xhr request in the Network tab. If an xhr request exists, hover over the Initiator column in that row and see if there is a line that reads setTimeout(async). If that is the case, see if enabling Timed action support helps capture this action. If this does not work, or if the Initiator contains setInterval(async) or Promise(async), manual instrumentation is necessary. See Missing XHR actions when promises are used for more details.

The following image shows a typical xhr request in Chrome DevTools, with setTimeout(async) in the initiator data.

Make sure the correct modules are activated. Perform the action and use Chrome DevTools to see if the Network tab contains a request with the fetch or xhr type. Enable the correct module—fetch or a more specialized module for fetch, BasicXHR, or a more specialized module for XHR actions.

If there appears to be a missing link between a user action and its distributed trace, check the following:

Verify that web requests are captured: Make sure that the server handling the web requests is instrumented with OneAgent and the web request is visible in Dynatrace. If some of the expected distributed traces are missing, check if OneAgent has adjusted the amount of data sent to the Dynatrace Server due to heavy load. See Adaptive traffic management for distributed tracing for details.
Verify that RUM is supported for the technology: In general, for distributed traces to be linked to their user actions, the technology on the first instrumented application tier must be one of the technologies listed in Technology support - Real User Monitoring - Web servers and applications or, for XHR calls, also in Deploy OneAgent as AWS Lambda extension.
Verify that RUM is enabled on the process group: You must enable RUM on the process group that handles the request. If your application consists of multiple tiers, enable RUM at least on the first tier (the tier nearest to the browser). For details, see Real User Monitoring for process groups.
Check if the web request is a cross-origin request. If it is, follow the instructions in Link cross-origin XHR user actions and their distributed traces.
Check if there is a cookie domain issue: Host name determination issues might impair the automatic determination of the cookie domain, or the cookie domain might have been misconfigured manually. See Configure the RUM cookie domain for web applications for details.
Make sure that your firewalls and proxies let RUM cookies and headers pass through. See Firewall constraints for RUM for details.
If you configured your infrastructure to add the HttpOnly attribute to dtCookie, remove this attribute; it is not supported for RUM cookies. See Cookies for details.

If you configured the cookie domain manually, make sure that it does not overlap with the cookie domain of another application. For details, see Configure the RUM cookie domain for web applications.
Make sure that your firewalls and proxies let RUM cookies pass through. See Firewall constraints for RUM for details.
If you configured your infrastructure to add the HttpOnly attribute to dtCookie, remove this attribute; it is not supported for RUM cookies. See Cookies for details.

When an action is active with a user input and XHR, the RUM JavaScript sets the dtPC request cookie value. This value contains pageId and actionId and may also contain serverid and visitid values in the value string. To see the value, use Chrome DevTools. To see the dtPC request cookie value, perform the desired action in your application, go to the Network tab, and find the request name in the Name column. Select the request name, go to the Cookies tab, and check the value for the dtPC request cookie, as shown in the following image. The format for the Dynatrace dtPC request cookie values is <serverId>$<pageId>h<actionId>v<visitId>.

If your page requests resources from other domains, the Timing-Allow-Origin HTTP response header needs to be set. Otherwise, the browser can't supply the values, and they can't be displayed in the Contributors breakdown chart. If this happens, a message appears in the chart area stating that network and server time can't be calculated because Dynatrace didn't receive W3C resource timings.

Starting with November 2022, browsers implemented a stricter referrer policy. This resulted in missing subdomain source actions for your applications monitored with Dynatrace.

The referrer policy controls the document.referrer property on a target page. After the default referrer policy changed from no-referrer-when-downgrade to strict-origin-when-cross-origin in 2022, document.referrer is populated only with the origin, while the full URL of the source page is stripped away for cross-origin requests. For example, if you navigate from https://www.dynatrace.com/pricing to https://community.dynatrace.com, the document.referrer on the target page contains just https://www.dynatrace.com.

As the full URL of the source page is truncated, Dynatrace can't determine the exact origin of the navigation and has to drop the source action information. This results in navigation actions that are shorter than they would have been if the full URL of the source page had been available.

To fix this issue, set the referrer policy of the origin page to no-referrer-when-downgrade either via the Referrer-Policy HTTP header or inside HTML. This will populate document.referrer on the target page with the full URL of the source page (only when the protocol security level stays the same or improves: HTTP > HTTP, HTTP > HTTPS, HTTPS > HTTPS).

Privacy-focused browsers like Brave ignore the set referrer policy, so it's always strict-origin-when-cross-origin. For this reason, Dynatrace can't generate source actions for subdomain navigations within such browsers.

Check the following things if some required metadata is missing.

See if the RUM JavaScript can capture the value right now.

The RUM JavaScript offers the dtrum.getAndEvaluateMetaData() function that captures all the configured metadata and lists the current values. If the metadata was not captured, then the function lists a reason for that.
- If the metadata expression is not listed, the page you are currently on might not be mapping to the correct application.
- If the metadata expression shows the data you intended to capture, the data might not be available when the RUM JavaScript is capturing it. The data is captured whenever an action is finished, so if the data is only available afterwards, then the RUM JavaScript cannot capture these values.
See if the JavaScript variable or DOM element is contained in a Frame or IFrame.

IFrames and Frames have their own JavaScript context, so it's impossible to access variables that are only available in another frame. DOM elements must also be available in a Frame or IFrame in which the RUM JavaScript is injected because IFrames can have access restrictions.

You can use Chrome DevTools to verify JavaScript variable or DOM element capture. To do this, perform the desired action in the application. Then go to the Console tab in Chrome DevTools, and then check the log for DOM Element value and Variable value entries. Ensure that those entries have valid values.

The following image shows a DOM Element access in the IFrame that contains the DOM Element:

This image shows a DOM Element access in the IFrame that doesn't contain the DOM Element:
See if the DOM selector is wrong or the querySelector isn't available.

Perform the following actions to verify that the DOM selector is correct:
- Make sure document.querySelector is available by typing it into the Chrome DevTools console. If it's not available, you won't be able to capture values in this browser. However, this is unlikely as document.querySelector is supported even by older browser versions.
- Make sure document.querySelector('yourselector') returns the value you want to capture. If not, then your queryselector is incorrect and the RUM JavaScript is not reporting data. See W3C Selectors API for more information about queryselector.
To check the return value for document.querySelector, perform the desired action in the application. Then in Chrome DevTools, go to the Elements tab, do a string search for document.querySelector, and verify the return value.

The following image shows data correctly returned from document.querySelector:
See if the cookies are using HttpOnly.

If the cookies have the HttpOnly flag set, the RUM JavaScript can't access its values and the value isn't reported, as shown in the following image.

You can check if the HttpOnly flag is set for cookies in the Application tab of Chrome DevTools.
Ensure that cookies are set on the correct domain.

Sometimes cookies aren't set on the correct domain, even though they appear in Chrome DevTools. This means that you can see the cookie value in Chrome DevTools, but the cookie isn't accessible from the RUM JavaScript.

To try this, you can search the document.cookie string in the Chrome DevTools console and check if the return string contains the cookie you want to capture.

If you notice your sessions aren't correctly tagged or if you have missing metadata, it's likely due to the application data privacy setting called Do Not Track.

For this setting, the Capture anonymous user-session data for "Do Not Track" enabled browsers option is enabled by default, which is an important element of RUM data privacy. This option ensures that Dynatrace only captures anonymized sessions when the "Do Not Track" setting is detected in users' browsers.

You can change the Do Not Track setting for your application. Note that if you select the Disable Real User Monitoring for "Do Not Track" enabled browsers option, RUM is turned off when the "Do Not Track" setting is detected in users' browsers.

For detailed instructions, see Configure Real User Monitoring according to GDPR | Do Not Track.

Why don't I see my applications or monitoring data?

General troubleshooting

Possible reasons for failure

Action-related troubleshooting

Metadata-related troubleshooting