Skip to content

CONCEPT Cited by 3 sources

Real user monitoring (RUM)

Definition

Real user monitoring (RUM) is a passive, inside-out observability technique: an in-page SDK captures what is actually happening in real users' browsers — Core Web Vitals, JavaScript errors with stack traces and user context, and session data — across the real devices, networks, and geographies users actually have. Grafana Cloud's RUM product (Frontend Observability) is powered by the open-source Grafana Faro SDK: instrument the app with a lightweight JavaScript snippet and it streams these signals to a Grafana-compatible backend (Source: sources/2026-08-24-grafana-from-failed-check-to-real-user-impact-pairing-synthetic-monitoring-and-frontend-observability).

Population sample, not controlled experiment

RUM is the epistemic opposite of synthetic monitoring. Every real session is effectively unique — different user, device, browser, OS, network, geography. No single session tells you whether a problem is your code, a spotty connection, or an aggressive browser extension. The signal is not in any one sample; it's in the broad pattern across many (Source: sources/2026-08-24-grafana-from-failed-check-to-real-user-impact-pairing-synthetic-monitoring-and-frontend-observability):

If you aggregate enough sessions, commonalities begin to surface: every affected user is on Chrome, or in a single region, or hitting the same JS error.

So: synthetic gives you a few samples you can trust individually; RUM gives you thousands to trust in aggregate.

What RUM uniquely supplies

Where a synthetic check can only say a user will fail, RUM answers the three questions synthetic structurally cannot (Source: sources/2026-08-24-grafana-from-failed-check-to-real-user-impact-pairing-synthetic-monitoring-and-frontend-observability):

  • Scope — how many real users were affected.
  • Duration — when the issue actually started in the real world, not just when the check cadence caught it (RUM commonly predates the synthetic alert by minutes).
  • Severity — what users actually experienced: a hard failure or a slow degradation.

This is what turns "a check failed, investigating" into "the checkout flow has degraded for ~8% of EU users since 09:07."

Captured signals

  • Core Web Vitals from real sessions: loading, interactivity, visual stability — as users actually experience them.
  • JavaScript errors with stack traces and surrounding user context, including the errors that were never scripted into a synthetic check.
  • Session Replay — visual playback of a user's journey from entry to exit, to see exactly what happened before something broke.

Complement, don't replace

RUM does not replace synthetic monitoring and vice versa. Together they form closed-loop reliability: a synthetic alert fires and you pivot to RUM to scope it (synthetic-alert-to-rum-pivot); RUM reveals an untested path and you codify it as a synthetic check (rum-gap-to-synthetic-check).

Seen in

  • sources/2026-08-24-grafana-from-failed-check-to-real-user-impact-pairing-synthetic-monitoring-and-frontend-observability — Grafana Cloud Frontend Observability (Faro-powered RUM) as the inside-out signal that scopes blast radius after a synthetic alert.
  • sources/2026-09-23-github-rendering-huge-pull-requests-in-the-github-copilot-app — RUM discipline applied inward, as permanent app-owned invariant probes. Rather than sprinkling throwaway console.logs and measuring their own hand-rolled instrumentation, GitHub's Copilot-app PR surface carries permanent structured probes answering invariants on every render (is the surface viewport-bound? how many rows/blocks mounted? is measurement coalescing to one commit per frame? how large are scroll corrections? did any comment block get inserted after scroll started — must be zero? are per-block observers leaking?) and asserts them as budgets in CI. Same "instrument with the app's real signals, not throwaway logs" principle as RUM, plus a requestAnimationFrame jank sampler and an unattended autopilot that reads the app's on-disk log — extending RUM's population-signal idea into a deterministic detector-grade harness. Pairs with patterns/measurement-driven-micro-optimization.
  • sources/2026-04-17-cloudflare-agents-week-network-performance-update and sources/2026-10-02-cloudflare-2026-birthday-week-network-performance-update — RUM as a comparative-benchmarking substrate, not just self-observability. Cloudflare runs a silent background probe in real visitors' browsers that times TCP handshakes against five CDN providers (Cloudflare, Amazon CloudFront, Google, Fastly, Akamai), aggregates per-network with the trimean, and publishes provider rankings on Radar Internet-Quality — "the difference between testing a car's top speed on a track versus watching how people actually drive on the highway." The Oct 2026 post makes the population-size argument explicit: the original probe ran only on Cloudflare-branded error pages (a narrow cohort); adding Turnstile Challenge Pages as a second RUM source massively widens the measured networks/geographies, which narrows the confidence interval around each provider's trimean so ~1 ms close races (CF 50 ms vs Fastly 51 ms) stop flipping on day-to-day noise. This is RUM's population signal applied to ranking stability — a direct instance of benchmark- methodology-bias mitigation by changing the sampling distribution rather than re-running the same samples. Caveat: both cohorts (error-page, challenge-page) carry selection bias and are not a clean random sample of all Internet users.

Merged aliases

  • real-user-measurement
Last updated · 766 distilled / 2,225 read