RUM | Setup and Basics

Real User Monitoring (RUM) reports data from real user sessions to paint a clear picture of a site’s performance compared against baseline data.

RUM reports on end user metrics that breakdown:

This guide assumes you are logged into and attempting to add RUM. For RUM: Legacy, see our documentation here

To skip to a specific section of the "Setting Up a RUM Check" video, click the links with the youtube-logov4.svg!

Table of Contents

Setting Up a RUM Check


youtube-logov4.svg Skip to 0:23

Basic RUM setup involves filling in a domain, retrieving a code snippet, and placing that code snippet before any scripts you wish to track with RUM (usually within the <head> attributes). Without placing the snippet in your site’s code we are unable to retrieve data.

To add a RUM check, Click Monitoring > Checks followed by Add New, and select Real User Monitoring from the Check Type dropdown. Once you click Save, will provide the RUM code snippet.

RUM Save check.gif


About RUM Requests

RUM can monitor one domain per 100,000 requests e.g., 5 domains would require 500,000 RUM requests allocated to your account. A single domain can also generate more than 100,000 RUM requests but will stop generating data once the account’s requests are fully used. 

An account owner can add additional requests at any time via Billing>Subscription.

See your Account Usage page for limits. 

Please note: RUM requests will be accumulated and available in reports for a total of 13 months regardless of your account tier.


Placing the RUM Code Snippet


Here is an example of the RUM code snippet that must be placed before any scripts you wish to track with RUM: 

<script>(function(w,d,s){w._uptime_rum2={};w._uptime_rum2.errors=[];w._uptime_rum2.uuid='UNIQUE_ID';w._uptime_rum2.url='';s=document.createElement('script');s.async=1;s.src='';d.getElementsByTagName('head')[0].appendChild(s);w.addEventListener('error',function(e){w._uptime_rum2.errors.push({t:new Date(),err:e})});})(window,document);</script>

Here is an example where the snippet has been placed correctly within the <head> attributes, before all scripts we want to track:


RUM loads asynchronously and has a near zero impact on site performance (comparable to a snippet such as the one used for Google Analytics).

Required Fields


youtube-logo-final.svg Skip to 0:41

The following fields are required before saving RUM. 




Provide the domain name that you will monitor with RUM. 

Subdomains are tracked by default as long as the subdomain URL you wish to track has a RUM code snippet. In the event of RUM tracking for a subdomain only, enter the root domain name in the Domain field and place the code snippet on only the subdomain pages. No further URL grouping is required for subdomain monitoring, although URL grouping is always recommended. 

It is possible to track third party domains as an Optional parameter



By default, we aggregate reports based on the median of your data set. The median of a set of numbers is the middle number in the set (after the numbers have been arranged from least to greatest), so it helps provide a snapshot of a data series that is less sensitive to outliers that might otherwise skew results. 

Aggregation also affects reporting, and can provide deeper insights into the user experience for certain segments of users. 

About Apdex


Apdex stands for Application performance index, which is an open standard developed to measure the performance of software applications. It is designed to convert raw measurements into more specific insights about user satisfaction with the state of your applications.

Apdex has three designated user expectations:

  • Satisfied - Satisfied users are fully productive, AKA not impeded by response time

Satisfied is less than or equal to the designated threshold.

  • Tolerating - Tolerating users notice performance dips, but will usually continue

The Tolerating score is assigned when the value is less than or equal to 4 multiplied by the threshold set for this check.

  • Frustrated - Frustrated users find performance unacceptable, and may abandon

Frustrated is greater than 4 multiplied by the designated value of the threshold.

The Apdex formula takes the total number of satisfied users, adds half of the tolerating users plus none of the frustrated samples, divided by all the samples. Below is an example of how Apdex is calculated:


Image courtesy of

See our documentation on Apdex for more information.

Customizing your Apdex Threshold

Changing the Apdex threshold from its default of 4000ms manually overrides the threshold for Satisfied, and the thresholds for Tolerating and Frustrated adjust accordingly. 

Optional Fields


youtube-logov4.svg Skip to 2:11

These fields are optional, but can improve the precision of RUM if any of these use cases apply to your application. We recommend reviewing these optional fields during check setup, as changes to Allowed External Domains after initial setup will require an update to your code snippet.

Rum optional.png

Excluding User-Agents and Why


Bot traffic, and other automated sources of traffic, can generate data in unexpected or unintended ways; for example, outside tracking used on a marketing landing page or event tracking for analytics purposes. Such bot traffic could potentially reflect inaccurate bounce rates or affect the precision of load time metrics. 

To exclude user-agents, list them one per line. uses substring matching, so it is possible to exclude a user-agent simply by using its name, one per line:

  • User1
  • Agent2
  • String3 

If all of your user-agents share a common term, such as a particular domain name, you can exclude them by identifying that domain:


Can all be excluded with:

RUM excludes most frequently used bots by default, some notable examples being:

  • Uptime
  • Googlebot
  • Mediapartners-Google
  • AdsBot-Google
  • Google-Read-Aloud
  • googleweblight
  • Bingbot
  • AdIdxBot
  • BingPreview
  • Slurp
  • DuckDuckBot
  • Baiduspider
  • YandexBot
  • Sogou
  • Exabot
  • facebot
  • facebookexternalhit
  • ia_archiver
  • AhrefsBot
  • SEMrushBot
  • DotBot
  • MauiBot

Allowing External Domains and Why


External domains can affect AJAX calls or other scripts that affect Time to Interactive (TTI), such as external calls made to a third-party service to retrieve raw data. Such examples might be considered “necessary” for a page to be considered fully interactive, and RUM has the capability to include data on performance of these external domains. 

Note: Fonts and other static assets are tracked by default automatically in corresponding metrics regardless of whether or not they are hosted on the current domain or an external one.

To allow these external domains, list them one domain name per line.

Please note that allowing external domains will require you to change and reapply your RUM snippet. 

URL Groups


URL Groups are useful when you are reporting on RUM data for a domain. For example, monitoring all service pages versus all marketing or all blog pages. When URLs match a specific pattern, you can group them together to make reporting more accessible and presentable. 

URL grouping allows for regex, so complex matching is possible. Here are some examples:


/application/user.*/:user page


We suggest this Regex cheatsheet and tester to help test your RegEx strings.

Note: if this field is used after the RUM check has been running, it will also retroactively group the data collected.


Excluding URL Parameters


You are able to exclude URL parameters from RUM to avoid tracking sorted or filtered content as unique. Add in the parameter value without the (?) question mark or (=) equal sign. Some examples are below:

  • To filter use “most_reviewed”
  • To filter use “device_type”
  • To filter use “client”

Note: if URL parameters are applied to an an existing RUM that has already been running, they will only affect newly collected data and will not delete previously accumulated data. It may take a few moments before updated parameter settings are propagated to the collectors and are reflected in the data.


Disable AJAX Tracking


There is a checkbox which will provide the option to Disable AJAX Tracking. This is so that you are able to reduce the number of RUM requests being consumed into your account, allowing you to optimize the usage.

The selection will reduce the number of RUM requests on your account, and the option will remain active and constant for future sessions unless manually toggled off.

Please Note: By setting the option to Disable AJAX Tracking, this will mean “all” calls will not be collected.


RUM Tracking and Transaction Checks


Please note that transaction checks that are run on a page which also contains a RUM collector script will not record events generated by checks. When running a transaction check on a page that also includes a RUM collector script, you may see the following message:

Response 406 received for
Failed to load resource: the server responded with a status of 406 ()

This does not indicate an error in the transaction check; it simply means that the RUM collector script is incompatible with the transaction check.


Configuring Data Region for RUM offers the ability to select between EU and US regions for RUM checks. Managing your data region can provide better reporting based on where your websites and data are hosted. 

To configure your data region for RUM, navigate to Settings > Account Details and choose your desired region for RUM then click Update Details: 


The change will be applied immediately, but it may take a few minutes for the changes to propagate to the collector and to be reflected in the UI.


Basic RUM Tips


RUM is useful for insights into the user experience, and as a result works well with synthetic monitoring. We highly recommend using Transaction monitoring in combination with RUM checks for several reasons:

  • Know when critical transaction pathways fail (RUM will only show an increase in 4xx, 5xx, or JS errors, while Transaction checks will alert you when a pathway fails)
  • Gain insights into performance over time (The Transaction check’s performance metrics are the total of all steps, where RUM provides unique insights into each URL’s performance from server response to interactivity)
  • Inform application management (RUM data combined with transaction uptime % can inform your team where to focus efforts in development and allocation of resources) 

We highly recommend examining RUM data by adjusting data aggregation, as it can help to zero in on more than just the median or average and find out how many users may be affected by performance issues. 

We also suggest utilizing URL groups as applicable to help manage the flow of data and make it easier to drill down into services or facets of your site. 

Build RUM into your deployment process so that new URLs will always receive the snippet, and data is generated automatically. 

The RUM checks page breakdown has an Error Rate column, which lists the error rate and type that has changed the most in the past 30 minutes. A certain percentage of Javascript (JS) errors may be expected as part of normal operation, but 4xx and particularly 5xx errors may signal a problem is brewing. 


Want to see the rest of our Checks in action? Check out our youtube-logov4.svg Youtube Library for more!


Was this article helpful?
1 out of 1 found this helpful



Article is closed for comments.

Have more questions?
Submit a request
Share it, if you like it.