Real User Monitoring: What RUM Sees and What It Misses
Real user monitoring times pages inside visitors' browsers. Here is what those APIs report, how much of it never arrives, and why it cannot detect an outage.
Real user monitoring is the practice of timing a page from inside the browser of a person who actually loaded it. A small script reads the browser's own performance timings and sends them to a collector. The result is field data: what your audience experienced on their devices, their networks and their browser versions.
What the browser actually reports
The numbers do not come from the script. They come from APIs the browser already maintains, and the script just reads and forwards them. MDN's glossary entry describes the technique as measuring a page from real users' machines, which is precise about where the clock lives.
Vendors label the product RUM, and the acronym and the full phrase mean the same thing everywhere you will meet them. Three families of metric usually travel together.
| Metric family | Example | What it answers |
|---|---|---|
| Navigation timings | DNS, connect, TLS, response start, DOM content loaded | Where the page load spent its time |
| Core Web Vitals | LCP, INP, CLS | How the load and the interactions felt |
| Errors and context | JavaScript exceptions, device, country, connection type | Who it was bad for, and why |
Google's Core Web Vitals guidance defines the second row, and the thresholds have moved more than once, so pin the version you report against. Interaction to next paint is the current responsiveness metric as of September 2026.
How the data gets home
The script buffers observations and posts them when the page is about to disappear, usually with navigator.sendBeacon so the request survives the unload. That design has a consequence people rarely plan for. A metric that is only final at the end of a session, such as cumulative layout shift, is lost entirely when the beacon fails.
Sampling is the other lever. Collecting every session from a high-traffic site is expensive, so most real user monitoring deployments sample. A one percent sample of ten million pageviews is plenty for a p75. A one percent sample of four thousand pageviews tells you almost nothing about your slowest country.
How much real user monitoring data never arrives?
More than most dashboards admit. Content blockers remove third-party collection scripts by default, consent banners suppress it until someone clicks accept, and corporate proxies drop the beacon endpoint. Browsers that restore a page from the back/forward cache report a load that never happened the way your chart assumes.
The bias is not random, which is the part that matters. The users most likely to block the script skew technical, and the users most likely to refuse consent skew privacy-conscious in specific regions. Your field data is a survey with a self-selected response rate, and it is worth knowing roughly what that rate is before arguing about a 40ms regression.
Field data and lab data disagree on purpose
Lab tools run one page load on controlled hardware and give you a repeatable number. Field data gives you a distribution from hardware you have never seen. The Chrome UX Report publishes that distribution for eligible origins, collected from real browsers based on browser options that determine eligibility.
When the two disagree, the lab is usually right about the cause and the field is always right about the impact. We prefer to set targets from the field and debug in the lab, never the reverse. A p75 that only moves for one device class is a real problem that a single lab run will never reproduce.
Why this technique cannot page anyone
Here is the boundary that decides your architecture. Field data requires a page load, and a page load requires a working site. When the origin returns 503 to everyone, no script runs, no beacon is sent, and the chart goes flat rather than red.
A flat line means either perfect health or total failure, and nothing in the data distinguishes them. Overnight traffic troughs produce the same shape. An external probe has no part in this collection path, because it never loads in a visitor's browser and never reports what a visitor felt.
That is why availability comes from a scheduled check running from somewhere else entirely. The trade-offs of that second vantage point are covered in synthetic monitoring, and the two browser-shaped approaches sit side by side in browser monitoring.
Common mistakes
Reporting an average. The mean hides the tail where your unhappiest users live. Use p75 or p95, the way the vitals thresholds are defined, and the reasoning is the same one set out in response time monitoring.
Comparing across a consent change. Turning a banner on or off changes who is measured, so the metric moves without the site changing. Annotate the deploy.
Treating a quiet dashboard as an all-clear. Zero sessions reported is an alerting condition in its own right, and it is the one thing this data source cannot raise by itself.
Sampling before you have traffic. Below a few thousand sessions a day, sample at one hundred percent and worry about cost later.
Real user monitoring answers how the site felt for the people who arrived. It cannot answer whether anyone could arrive, and no amount of front-end instrumentation changes that. Pair field data with an independent check that runs on a schedule whether or not traffic exists, and put that check on the endpoint your revenue depends on. Plan limits for the scheduled half are on the pricing page.
FAQ
It is the practice of timing a page inside the browser of a person who actually loaded it. A script reads timings the browser already maintains, such as navigation timings and Core Web Vitals, and sends them to a collector. The result is field data describing what your audience experienced on their own devices and networks, rather than on test hardware.
RUM measures real sessions and only exists when someone visits. Synthetic monitoring generates its own traffic on a schedule, so it produces a data point at 4am with no visitors at all. RUM gives you coverage of every device and network your audience uses. Synthetic gives you a repeatable baseline and an availability signal that does not depend on traffic.
Not reliably. Field data needs a page load, and a page load needs a working origin. When a site returns errors to everyone, no script runs and no data is sent, so the chart goes flat rather than red. A flat line looks identical to an overnight traffic trough, which is why availability detection has to come from an independent scheduled check.
Usually three families. Navigation timings cover DNS, connection, TLS, response start and document events. Core Web Vitals cover largest contentful paint, interaction to next paint and cumulative layout shift. Context and error data cover JavaScript exceptions, device class, country and connection type, which is what turns a slow percentile into an actionable segment.
The Chrome UX Report publishes field data for eligible origins, collected from real browsers based on browser options that determine eligibility. Sites qualify only if they are publicly discoverable and have enough visitors for a statistically significant dataset. It is a good free baseline, but the data is aggregated and delayed, so it will not replace your own collection.
Related reading
- Browser Monitoring: Three Products, One Phrase - Browser monitoring means real user data, a scripted headless browser, or staff surveillance. Here is how to tell which one a vendor is selling you.
- Synthetic Monitoring: The Three Rungs Explained - Synthetic monitoring generates traffic on a schedule so failures surface at 3 am with no users online. Here are its three tiers and what each one costs.
- Response Time Monitoring: Phases, Percentiles, Regions - Response time monitoring works when you read the timing waterfall, alert on p95 instead of the mean, and compare probe regions rather than blending them.