Set up an auto-injected frontend in the New RUM Experience

  • Latest Dynatrace
  • How-to guide
  • Published Oct 29, 2025
  • Preview

As explained in Find the suitable instrumentation approach, automatic injection is available if at least one application tier can be instrumented with OneAgent, and automatic RUM injection is supported for that technology. For details, see Technology support - Real User Monitoring - Web servers and applications. This guide explains how to create a frontend in the New RUM Experience and configure frontend detection rules to ensure captured data is routed to the correct frontend.

Step 1

Deploy OneAgent

Step 2

Learn how frontend detection rules are applied

Step 3

Account for uninstrumented components

Step 4

Create a frontend and define frontend detection rules

Step 5

Set the order of frontend detection rules

Step 6 optional

Configure the RUM JavaScript snippet format

Step 1 Deploy OneAgent

After deploying OneAgent in full-stack monitoring mode on your application tiers, the RUM JavaScript is automatically injected into HTML pages. For Java applications, restart the process after OneAgent deployment for the injection to become active. For installation details, see Dynatrace OneAgent.

If OneAgent doesn't inject the RUM JavaScript, refer to Configure automatic injection for guidance.

By default, all captured RUM data is associated with the catch-all frontend My web application. We recommend keeping this name to make it easier to distinguish from other frontends.

If you can’t find My web application, it may have been renamed.

To locate the renamed My web application

  1. Go to Experience Vitals Experience Vitals.
  2. Select Web to view all web frontends.
  3. Select any auto-injected frontend.
  4. On the Settings tab, select Frontend detection.
  5. Select the link catch-all frontend. You'll be redirected to My web application.

Step 2 Learn how frontend detection rules are applied

Frontend detection rules are evaluated on the server side of your application by the OneAgent on the first instrumented tier—the one closest to the browser.

All frontend detection rules are URL-based and consist of a pattern and a matcher. There are two ways to define them:

  • On the entire URL: You can use the matchers URL starts with, URL ends with, URL contains, and URL equals. The URL follows the format scheme://host:port/path?query, where the query string is optional and default ports (80 for HTTP and 443 for HTTPS) are omitted. The URL does not include a fragment identifier (as in scheme://host:port/path?query#fragment), because fragments are only used by the browser and never sent to the server.
  • On the domain only: The rule is applied to the host portion of the URL. The matchers Domain (host) starts with, Domain (host) ends with, Domain (host) contains, Domain (host) equals, and Domain (host) matches are available. When using the latter, the pattern example.com matches both example.com and shop.example.com.

Step 3 Account for uninstrumented components

There may be a component—such as a reverse proxy or load balancer—between the browser and the tier responsible for frontend detection that is either uninstrumented or uses a technology without RUM support. If this component rewrites the URL, the URL used for frontend detection differs from the one originally requested by the browser. In such cases, special considerations are required to ensure that your frontend detection rules take effect as expected.

  • If the component terminates HTTPS, you cannot use the https scheme in the pattern of a frontend detection rule.
  • If the component rewrites the host part of the URL, you can still use the original host in your frontend detection rules. However, you may need to set up host name determination for this to work. For details, see Set up host name determination in the New RUM Experience.
  • If the component rewrites the URL path and removes part of it, you cannot use that removed part in your frontend detection rules.

Step 4 Create a frontend and define frontend detection rules

With the foundational knowledge from the previous steps, you are now ready to create a frontend and define its detection rules.

To create an auto-injected frontend

  1. Go to Experience Vitals Experience Vitals.
  2. Select Frontend to start the Frontend creation wizard.
  3. In the Start monitoring step, select the frontend type Web and provide a frontend name.
  4. In the Select instrumentation method step, select OneAgent injection.
  5. In the Create your new frontend step, select Create.
  6. In the Setup step, configure the matcher and the pattern for your frontend detection rule.
  7. Under Enablement and cost control, check if New Real User Monitoring Experience is enabled. If it isn’t, select Override and turn it on.
  8. Select Go to new frontend.

You’ll now see the detection rule for the frontend you just created. To add additional rules, select Add.

You can create up to 1,000 frontend detection rules per environment.

Step 5 Set the order of frontend detection rules

Frontend detection rules have a defined order, and OneAgent applies them sequentially. Rules at the top of the list take precedence over those further down. To ensure accurate detection, place more specific rules—for example, those that include both a domain and a path—higher in the list than generic rules—such as those that include only the domain.

The rules you created in the previous step are added to the bottom of the list, so you may need to move them up for them to take effect. To adjust the order, go to Settings Settings > Real User Monitoring > Application detection. Select and hold Drag handle next to the rule name, then drag the rule up or down to change its priority.

When you update your frontend detection rules, the changes are usually communicated to OneAgent within a minute. However, there are scenarios where the updated rules cannot take effect immediately.

When OneAgent injects the RUM JavaScript, it adds an ID for the detected frontend to the injected snippet. This ID is then included when the RUM JavaScript reports the captured user events, allowing the events to be correctly attributed to the corresponding frontend. In the following situations, OneAgent cannot perform a fresh injection with an updated ID, which delays the effectiveness of rule changes:

  • HTML served through a CDN or other cache: OneAgent can inject the RUM JavaScript only when the HTML code is evicted from the cache and requested again from the instrumented origin server.
  • Long expiration times for HTML documents: If the application specifies a long expiration time using the Expires response header or the max-age directive of the Cache-Control header, changes to frontend detection rules cannot take effect until the cached document expires.
  • Single-page applications (SPAs): SPAs rewrite the current page dynamically instead of loading a new page from the server. If the HTML was loaded before the rule changes, the categorization of captured user events does not reflect the updated configuration, which takes effect as soon as the page is refreshed.

Step 6 optional Configure the RUM JavaScript snippet format optional

By default, OneAgent injects the OneAgent JavaScript tag snippet format, which is recommended for most scenarios.

The New RUM Experience provides snippet formats tailored to different requirements. For details on different formats and their configuration options, see Select a snippet format in the New RUM Experience.

Related tags
Digital Experience