A Synthetic monitor runs every five minutes and shows green, yet the RUM session view shows nothing from it. Or the reverse: Synthetic sessions pollute your usage charts. This guide explains why Synthetic RUM sessions go missing or blend in with real ones, and how to find them with a few ordered checks.
Goal: for a given browser monitor, know whether its executions attach to a RUM application, where to read them, and which cause to rule out first. For an SRE the mix-up is costly: an SLO computed over blended sessions misleads, and a misread low-traffic alert lengthens MTTR.
Scope: the documentation pages read cover Dynatrace SaaS (RUM Classic and the new session analysis on Grail); the rule on excluding Synthetic traffic also appears in the Dynatrace Managed documentation (RUM Classic). The DQL queries apply to SaaS only.
Synthetic RUM sessions: what Dynatrace separates, and what it does not
A browser monitor loads a real page in a real browser. If the page carries the RUM JavaScript, that run produces RUM data like any other visit. Dynatrace therefore tags its monitors’ traffic so it can be told apart.
The documentation on configuring browser monitors in Classic states that Dynatrace always adds a marker to the user agent, even when you set a custom one.
In the data model, the dt.rum.user_type field takes three values: real_user, robot and synthetic. Two fields are set only for the synthetic type: the monitor identifier and the step number.
In session analysis, the User type filter lets you choose robots, synthetic users or real users, and the Browser monitor filter selects the monitor used. Two consequences: a Synthetic session does exist in RUM, and an over-strict filter is enough to hide it.
Prerequisites
- An active browser monitor (see HTTP and browser Synthetic monitoring).
- A RUM web application whose pages visited by the monitor carry the RUM JavaScript (see configuring RUM).
- Access to the web server or CDN logs, or to Notebooks for the DQL query.
Step-by-step diagnosis
Step 1: check the view filters
Open the application’s session analysis and look at the User type filter first. A view filtered on real users hides Synthetic, and that is the method the documentation recommends to clean an analysis. Select the synthetic type, then the monitor concerned with Browser monitor. Skip this step and you may chase a fault that does not exist.
Step 2: count sessions by type with DQL
On SaaS, with the new RUM experience, count the last day’s sessions by user type:
fetch user.sessions, from:now()-24h
| summarize sessions = count(), by:{ dt.rum.user_type }
Then, for synthetic sessions, by monitor:
fetch user.sessions, from:now()-24h
| filter dt.rum.user_type == "synthetic"
| summarize sessions = count(), by:{ dt.synthetic.monitor.id }
If the first query returns synthetic rows but your monitor is absent from the second, the problem is attachment, not display. If it returns no synthetic row at all, go to step 3. The field names come from the RUM semantic model; confirm the exact case of the value in your environment (the model also documents « SYNTHETIC » in capitals for the dependent fields).
Step 3: prove the monitor reaches the page
Look for the user agent marker in the web server or CDN access logs:
grep RuxitSynthetic /var/log/nginx/access.log | tail -n 5
The path depends on your server, and the log format must include the user agent. No line means the monitor does not hit this server (wrong URL, CDN cache, redirect to another origin). Lines present means traffic arrives, so the cause lies in RUM injection or attachment.
Step 4: check the RUM JavaScript injection
A Dynatrace community article on automatic assignment of browser monitors (community support, not product documentation) lists these conditions:
- the pages visited by the monitor must actually carry RUM;
- for Synthetic runs, the RUM JavaScript must be the first script loaded on the page; real users are not affected by this order, which explains RUM working for users and empty for Synthetic;
- with manual injection, no rule may exclude Synthetic executions;
- the jsAgent file name must follow a supported format (
<name>_<hash>_<version>.jsor<appid>_complete.js), and its version must be supported.
These points come from the community; re-read them for your version and check the application health before turning them into a team rule. The article also states that assignment is detected at run time, not when the monitor is configured, and that it cannot be disabled if the monitor visits a RUM-injected page.
Step 5: check the application and detection rules
In RUM Classic, all traffic is assigned to the « My web application » application by default unless detection rules say otherwise. A Synthetic session may therefore sit in a different application from the one you expect. Look at the monitor’s assignment tab: the documentation says it lists auto-assigned and manually associated applications separately, and that manual associations can be dissociated. If the monitor is down, the associated application is considered unavailable.
What the exclusion settings do not do
A common reflex: block the Synthetic locations’ IPs in the application, or enable bot and spider exclusion to « clean » RUM. The documentation is clear: these settings do not block Synthetic Monitoring traffic. It adds that auto-assigned applications cannot be dissociated from Synthetic monitors. The intended method is the User type filter at analysis time. Bot exclusion also remains approximate, since it matches the user agent against patterns: some robot traffic may get through.
Billing: do not conclude from absence
The consumption documentation says sessions from synthetic users and robots are not counted when calculating RUM consumption. Consumption that does not rise after a monitor starts therefore does not prove RUM receives nothing. For more on units, see RUM metrics on Grail.
How to check that it works
- Run the monitor on demand and wait a few minutes.
- Re-run the step 2 query: a
syntheticrow must appear with your monitor’s identifier. - In session analysis, filter on synthetic User type and Browser monitor: the session appears.
- Confirm your user-facing SLOs filter on real users.
Best practices
- Filter by user type in every dashboard and SLO, rather than trying to exclude Synthetic at the source.
- Load the RUM JavaScript first in the
<head>. - Keep one monitor per critical journey and name it clearly: the Browser monitor filter becomes readable.
- Record in the runbook where to read synthetic sessions and how to tell them apart, in a blameless tone: a « missing » session is first a filter or a script order.
For a monitor on a private location or behind authentication, see also the Synthetic Recorder and private locations. Session replay is another topic: Session Replay on Grail.
Frequently asked questions
Do Synthetic sessions appear in RUM?
Yes, if the visited page carries the RUM JavaScript: the data model provides the synthetic type and the User type and Browser monitor filters. They are simply hidden as soon as the view is limited to real users.
Can I exclude Synthetic traffic from RUM?
Not with Synthetic location IP exclusion or bot and spider exclusion, according to the documentation. Use the User type: Real users filter at analysis time.
Do Synthetic sessions consume RUM volume?
According to the consumption documentation, sessions from synthetic users and robots are not counted when calculating RUM consumption. Synthetic monitor actions follow their own counting rules.
Conclusion
A Synthetic session missing from RUM almost always comes down to one of these: a view filter, a page without RUM, a script loaded too late, or an unexpected application. Check in that order, with DQL then access logs, before opening a ticket. Not verified here: assignment behaviour for the new-experience frontends (Experience Vitals), which sits on a different documentation page.
This site is an independent blog, not affiliated with Dynatrace LLC. Product names belong to their owners.
Originally published on span.observer. French version: https://span.observer/fr/sessions-synthetic-rum-absentes/.
Top comments (0)