Real User Monitoring vs. synthetic monitoring

Lesson 10's synthetic checks run from fixed, controlled locations, on consistent infrastructure, following a fixed script. This makes them reliable and comparable over time — and blind to the enormous variability of real devices, real network conditions, and real user behavior that a synthetic check's controlled environment specifically excludes.

Real User Monitoring (RUM) collects performance and error data directly from real users' browsers or apps as they actually use the product — page load times, specific interaction delays, JavaScript errors, all tied to the actual device, browser, network condition, and geography each real user experienced:

Unlike synthetic monitoring's single controlled data point, RUM produces a genuine distribution across everything real users actually bring — which is exactly the raw material lesson 2's percentile discussion applies to: a p95 load time across real users reveals what the worst-off meaningful share of actual visitors experience, not what one scripted check from one location experiences.

For web frontends specifically, Google's Core Web Vitals give a common, standardized vocabulary for real-user frontend performance:

These matter beyond pure engineering interest — search engines use Core Web Vitals as a ranking signal, and poor real-user scores can measurably affect a site's search visibility independent of any backend metric looking perfectly healthy.

A synthetic check running from a fast, well-connected data center can show a page loading in 400ms — completely accurate for that specific condition — while RUM data shows a meaningful share of real users on slower mobile connections experiencing 4+ second loads. Neither measurement is wrong; they're answering different questions about different conditions, and a team relying on synthetic checks alone can have a confidently green dashboard while a real, substantial share of actual users have a genuinely bad experience the synthetic check was never positioned to catch.

Synthetic monitoring's fast, reliable alerting catches regressions quickly and is the right tool to gate a deploy on. RUM's broad, realistic picture is the right tool for understanding and improving actual user experience over time, and for catching problems (a specific device class, a specific region's network conditions) that a synthetic check was never scripted to notice. Neither one alone gives the complete picture this domain's opening lesson argued no single pillar or tool ever does by itself.