What Is Real User Monitoring (RUM)?

Last verified on Nov 8, 2026.

Real user monitoring (RUM) measures how your website or app performs for the people actually using it. A script in the page, or an SDK in the app, records timings and errors in each visitor's browser and reports them to a collector. MDN describes it as measuring page performance from real users' machines, and web.dev says RUM data and field data are the same thing.

How RUM Works

Typically a small script is added to each page. As people use the site, their browsers report back what they experienced: page load timings, resource timings, errors, and usually some session context. MDN notes that RUM captures real usage regardless of device, browser, network, or location, and monitors actual use cases rather than the paths an engineer or product manager assumed.

The data comes from standard browser APIs. The Navigation Timing specification from the W3C defines an interface for complete timing information about a document's navigation, and PerformanceNavigationTiming is how you read it. MDN points to that interface and PerformanceResourceTiming as the main starting points for building your own collector. A minimal example:

const [nav] = performance.getEntriesByType('navigation')
navigator.sendBeacon(
  '/rum',
  JSON.stringify({
    page: location.pathname,
    interactive: nav.domInteractive,
    load: nav.loadEventEnd,
  })
)

Most teams use a library or a vendor client instead of hand-rolled code. AWS's CloudWatch RUM, for instance, collects client-side data from actual user sessions for web and mobile apps, samples a percentage of sessions that you choose, and breaks results down by device type and operating system.

Core Web Vitals in the Field

The best-known RUM metrics are the Core Web Vitals. web.dev defines them as:

A page passes when it meets all three at the 75th percentile of page loads, segmented across mobile and desktop. web.dev's field measurement guidance adds that you should use percentiles and not averages, report a distribution, and avoid tracking more than you need, because measurement itself can hurt performance. Its web-vitals JavaScript library is the usual way to collect them. For the monitoring side, see the guide on web vitals regressions.

What RUM Is Good At

• Seeing the long tail. Field data is a distribution. Some visitors load fast and others slowly, and RUM shows the spread.
• Segmenting. Break results out by browser, device, country, or release.
• Proving a fix worked. After a change, the 75th percentile either moves or it does not.
• Finding what you did not script. Users take paths nobody wrote a test for.

What RUM Is Not

It needs traffic. A page nobody visited at 3 a.m. produces no data, so RUM will not tell you the site is down overnight. MDN also points out RUM is more expensive and less convenient than synthetic testing. And it is noisier: differences between visitors mean one number rarely tells the story. web.dev's guide on lab and field differences covers why numbers from lab tools and field tools disagree. Synthetic monitoring fills that gap, and APM covers what happens on the server.

RUM, Errors, and Privacy

A RUM collector sees real people's sessions, so decide up front what it sends. AWS's client lets you sample a percentage of sessions, and web.dev advises against tracking more than you need. The guide on client errors covers browser exceptions, which most RUM tools also report.

Frontend Telemetry in Sazabi

Sazabi is an AI-native observability and security platform. Sazabi's Browser and React Native SDKs capture errors, console output, network calls with trace context, user interactions, navigation and session identity from web and mobile apps. They do not capture Core Web Vitals or session replay. Read about frontend breakage and client errors for what it surfaces from browser errors. For how page speed shows up on the server side, see latency spikes.