Configure and use Cloudmon RUM to monitor website and web application performance from the real visitor's perspective, diagnose slow pages and JavaScript errors, and set up alarms and reports.
Real User Monitoring (RUM) in Cloudmon enables web and IT teams to track, analyse, and diagnose the real-time and historical performance experienced by actual visitors to a website or web application. RUM captures data from a lightweight JavaScript snippet embedded in each monitored page, measuring Core Web Vitals, JavaScript errors, network resource timing, and session/device details directly from the visitor's own browser. Unlike synthetic checks, RUM reflects exactly what real users experienced, across every device, browser, connection type, and location that reached the site.
RUM is designed for per-page performance analysis, for diagnosing JavaScript errors affecting real sessions, for comparing performance across geographies and connection types, and for proactive monitoring that surfaces regressions before users report them. Navigate to Digital Experience → RUM in the top navigation bar to access all RUM views.
RUM monitoring requires two setup steps: adding the site to monitor, and installing the generated tracking snippet on that site's pages.
Navigate to Digital Experience → RUM and click Add. The Add RUM Site form has two sections.
Monitor Details
| Field | Description |
| Display Name | A friendly name to identify this site in the RUM Sites list, e.g. "My App - Production". |
| URL | The domain or URL of the site being monitored, e.g. "myapp.com". |
Collection Settings
| Field | Description |
| Sampling Rate (%) | The percentage of visitor sessions to record. 100% gives the most complete data; lower values reduce pageview quota usage on high-traffic sites. |
| Apdex T (ms) | The target response-time threshold used to calculate the Apdex satisfaction score for this site. |
| Bot Filter | Automatically excludes known bots and crawlers from RUM data. Enabled by default. |
| AJAX Tracking | Captures background XHR/fetch requests made after the initial page load, in addition to the page load itself. Enabled by default. |
| SPA Mode | Enable for single-page applications (e.g. React, Angular, Vue) so client-side route changes are tracked as separate pageviews without a full page reload. Disabled by default. |
| Excluded URLs | Path patterns to exclude from data collection, such as internal or admin-only routes. |
| Excluded IPs | IP addresses to exclude from data collection, such as office or VPN egress addresses, to keep internal traffic out of production metrics. |
| Domains to Exclude | Domains to exclude from data collection, such as staging or QA subdomains. |
Click Save to create the site. It appears in the RUM Sites table with the status Not Monitored until the tracking snippet is installed and begins receiving traffic.
Click the </> icon next to a site's name in the RUM Sites table to open the RUM Snippet dialog. Click Copy to copy the generated <script> tag, then paste it into the site's HTML, ideally immediately before the closing </head> tag on every page to be monitored.
RUM provides a consolidated RUM Sites dashboard and a per-site detail view accessible from the navigation bar.
The RUM Sites dashboard (Digital Experience → RUM) provides a summary of all monitored sites. Status tiles at the top show the count of sites that are Up, Critical, Trouble, Attention, or Not Monitored, alongside the account's monthly pageview quota usage. The sites table lists, per site, the RUM Status, LCP/CLS/INP at the 75th percentile, Apdex score, pageviews per hour, JS error rate, and sampling rate, with actions to enable/disable, edit, delete, or view the tracking snippet for each site.
Clicking a site name opens its detail view, which contains six tabs:
| Tab | What it shows |
| Overview | Apdex score, active alarms, Core Web Vitals cards, a Core Metrics Over Time chart, device/browser/connection/user breakdowns, a navigation timing waterfall, and a session-location map. |
| Pages | Per-URL breakdown of pageviews, Core Web Vitals, and error rate, to identify the slowest or most error-prone pages. |
| Errors | Unique JavaScript errors, total occurrences, affected sessions, and a table of each error message with its count and the page it occurred on. |
| Resources | Every network request the site makes (script, link, image, fetch, CSS, other), ranked by P75 duration and average transfer size. |
| Geo View | A world map of sessions by country, switchable between Apdex, Response Time, Page Views, Sessions, and Errors, with CSV export. |
| Alarms | Alarm rules and history configured for this site. |
RUM scores every page against Google's Core Web Vitals, which are used across the dashboard and detail views to colour-code performance as Good, Needs Improvement, or Poor. Understanding what each metric measures makes it easier to interpret the colour-coded badges seen throughout RUM.
| Metric | What it measures | Thresholds |
| LCP (Largest Contentful Paint) | Time until the largest visible content element on the page has finished loading. | Good < 2.5s Poor > 4s |
| CLS (Cumulative Layout Shift) | Visual stability: how much visible content unexpectedly shifts as the page loads. | Good < 0.1 Poor > 0.25 |
| INP (Interaction to Next Paint) | Responsiveness: the delay between a user's interaction and the page's next visual update. | Good < 200ms Poor > 500ms |
| Apdex Score | A composite 0 to 1 satisfaction score derived from response times relative to the configured Apdex T threshold. | Satisfied / Tolerating / Frustrated bands |
RUM is designed for active troubleshooting as well as proactive monitoring. Below are the most common scenarios where RUM provides immediate diagnostic value:
Diagnosing a slow page: Open the Pages tab and sort by LCP P75, or check the Slowest Page card, to find the worst-performing page. Cross-reference the Resources tab to identify which specific scripts, images, or API calls are contributing to the delay, and review the Navigation Timing waterfall on the Overview tab to see whether the delay is in DNS, SSL, server response, or content download.
Investigating a spike in JavaScript errors: Open the Errors tab to see Unique Errors, Total Occurrences, and Affected Sessions. The Most Frequent Error card and the Errors table show the exact message, count, and page for each error, which can be shared directly with engineering to reproduce and fix the issue.
Comparing performance by region: Open the Geo View tab and switch between Apdex, Response Time, and Errors to identify regions with degraded experience, which may point to CDN, DNS, or regional infrastructure issues rather than the application itself.
Excluding internal traffic from production metrics: Edit the site's Collection Settings and add office or VPN IPs under Excluded IPs, staging subdomains under Domains to Exclude, and internal-only paths under Excluded URLs, so internal and QA activity does not skew real-user metrics.
Cloudmon supports alarms on RUM metrics including Apdex score, LCP, CLS, INP, and JS error rate. Each alarm is built around a simple IF/THEN model, where you select a metric, set a threshold, and define what happens when it is breached. Learn more
| Issue | What to check |
| Site added but status stays "Not Monitored" | Confirm the RUM snippet has actually been pasted into the site's HTML and deployed to the live environment, not just saved locally. Open the page in a browser and check the Network tab for a successful request to rum.js. |
| Snippet is installed but no data is appearing | Check the browser Console for errors related to rum.js. A common cause is an incorrect data-site-id, an ad-blocker or privacy extension blocking the script, or the snippet being placed somewhere it never executes (e.g. inside a conditional that isn't reached). |
| CLS or another metric shows a bare "-" for a site | This indicates insufficient data has been collected yet for that metric. Allow more traffic to accumulate, or verify the sampling rate is not set too low for the site's traffic volume. |
| Some pages show data but others don't | Confirm the RUM snippet is present on every page template, not only the homepage. Single-page applications additionally require SPA Mode to be enabled so route changes are tracked as pageviews. |
| Excluded IP/URL/domain traffic still appearing in reports | Confirm the exclusion was saved under the correct site's Collection Settings, and that the pattern matches exactly (e.g. wildcard paths must include the *). Excluded traffic already collected before the change was saved will still appear historically. |
| Pageview counts differ between the Overview tab and Pages tab | Confirm both tabs are set to the same date range. Counts are calculated per the selected period and will differ if one tab's range was changed independently. |