Synthetic vs real user monitoring

There are two fundamentally different ways to know whether a website is working, and the difference between them explains most disagreements about whether a service is "up".

Synthetic monitoring sends artificial requests on a schedule from controlled locations. Real user monitoring instruments the actual application and reports what actual visitors experienced.

Synthetic: Consistent and narrow

The same request, from the same place, at the same interval. Because everything is held constant, a change in the result means a change in the system - Which makes synthetic data unusually clean for spotting trends and regressions.

It also works when nobody is using the site. A synthetic check running at 4am catches the outage that would otherwise be discovered by the first visitor at 7am. That is the single biggest argument for it.

And it is the only way to monitor a journey that involves making changes you do not want real users making - A checkout with a test card, a sign-up with a throwaway account.

What it misses: Everything it was not scripted to do. A synthetic check tests one path from one place with one configuration. Real users are on hundreds of device and network combinations, in every geography, doing things nobody scripted. A check from a data centre on a fast connection tells you nothing about a user on a congested mobile network.

Real user monitoring: Comprehensive and noisy

RUM works by embedding a small script that reports timing and error data from the visitor's own browser. Every visitor becomes a measurement.

The coverage is total. Every page, every device, every network, every geography - Weighted naturally by how much traffic each actually receives, which means you spend your attention where your users are rather than where you guessed they were.

It is also the only way to see the things that only exist in a real browser: A JavaScript error that happens on one browser version, an extension conflict, a slow third-party script, a Core Web Vitals score that only degrades on mid-range Android devices.

What it misses: The outage. This is the fundamental and unfixable limitation - A user who cannot load the page cannot report that they could not load the page. When a site is fully down, RUM data does not spike; it goes silent. A sudden absence of data is a signal, but it is a weak and ambiguous one, because low traffic looks the same.

RUM also cannot tell you about a problem before it affects someone, by definition. And it is noisy: A slow page load might be your server or it might be one user on a train in a tunnel, and you cannot always tell.

Side by side

Why you need both

Because the blind spots are complementary rather than overlapping.

Synthetic answers "is it up and is it getting slower" with a clean, controlled signal that works around the clock. RUM answers "what are people actually experiencing" with total coverage of everything you did not anticipate.

Run synthetic checks for availability and alerting, and RUM for performance work and for understanding the long tail. Use synthetic for the alert that wakes someone; use RUM for the investigation afterwards.

What this site is

Worth being explicit, since the distinction is exactly what this article is about.

The monitoring on IsItDown.now is synthetic: A probe every 20 minutes from one location against one URL per service. That gives a clean, consistent record and an outage log that cannot be manipulated - And it carries every limitation described above. It cannot see a regional outage, a broken mobile app, or a login failure behind a working home page.

The user report system is a crowd-sourced stand-in for RUM. It cannot measure anything, and it depends entirely on people choosing to tell us - But it notices exactly the failures a synthetic probe cannot, and it notices them immediately.

Neither is sufficient. Shown together, with their respective limitations stated, they cover more than either does alone. That is the whole argument for the design, and the methodology page spells out where each one falls short.

A note on RUM and privacy

RUM means shipping data about your users' browsing to a third party, and that carries real obligations. Choose a tool that samples rather than collects everything, that does not record session replays by default, and that lets you strip identifiers before they leave the browser.

The performance insight is genuinely valuable. It is not valuable enough to justify collecting more than you need.