Synthetic vs real user monitoring: what each one catches

What each one does

Synthetic monitoring, sometimes called active or proactive monitoring, sends a request you defined from a machine you control, on an interval you set. That request can be as small as an HTTP GET or as large as a scripted browser session that logs in, adds an item to a cart and checks out. Each run produces a result whether or not anybody visited the site.

Real user monitoring, usually shortened to RUM, is passive. A small script in your pages reports what the browser measured for that visit: navigation timings, resource loads, errors, and the Core Web Vitals as the visitor experienced them. It produces data only in proportion to your traffic, and it produces nothing when nobody is there.

What synthetic catches that RUM misses

• Outages at 4 a.m., or on any page with little traffic. If nobody loads the page, RUM has nothing to report, and a total outage is precisely the case where the beacon cannot be sent
• Availability from places you have no users yet, which is how you find out that a new market cannot reach you
• A clean baseline. The same script, from the same location, on the same interval, so a change in the number is a change in the site rather than in who happened to visit
• Multi-step flows you would not want real users to exercise, such as a checkout that would create a real order, or a login you can run against a test account
• Expiry and configuration failures that never reach a browser at all: certificates, DNS records, blacklist listings, open ports
• The first failure after a deployment, before the traffic that would have revealed it arrives

What RUM catches that synthetic misses

• The real distribution of devices, networks and locations. A synthetic check from a data center connection will never reproduce a mid-range phone on mobile data
• Third-party scripts, consent banners and personalization that only load for real sessions with real cookies
• Problems affecting a subset of users: one browser version, one region, one A/B variant
• Which slow pages matter, weighted by how many people see them
• Field Core Web Vitals, which is what search engines use, as opposed to the lab values a synthetic run produces

When you need both

The two answer different questions, so the split is usually clean. Use synthetic for anything you would page someone about: availability, response time against a threshold, certificate and domain expiry, and the critical flows that make you money. Those need to be true at 4 a.m. with zero traffic, and they need a stable baseline to alert against.

Use RUM for deciding what to fix. When a page is slow for some people, RUM tells you which people and how many, which is the information a prioritization argument needs and which a synthetic check cannot supply.

A practical setup is synthetic checks driving the alerts and the uptime record, RUM driving the performance backlog. If you can only run one, run synthetic: an unmonitored outage is more expensive than an unmeasured slow page, and RUM cannot report on a page that failed to load.

Where transaction monitoring fits

A transaction check is synthetic monitoring at its most detailed: a recorded browser script that walks through a real user journey step by step and fails on the step that broke, rather than on the site as a whole. It catches the class of failure that a simple availability check reports as healthy, where the home page returns 200 while the login form behind it is broken.

Because it is synthetic, it runs on a schedule with no traffic required, and because it drives a real browser it exercises the JavaScript, the third-party dependencies and the redirects that a plain HTTP check skips. HostTracker's transaction monitoring works this way, and the transaction check guide covers how a script is recorded and what each step reports.

Turning a measurement into an alert

Neither approach is useful until something acts on the result. A synthetic check is worth having because it runs whether or not you are watching, and because a failure can reach you immediately: HostTracker runs its checks from 300+ checkpoints in 158 cities across 13 monitor types, and sends alerts by email, SMS, voice call, Slack, Telegram and more when a result changes. Pair that with whatever RUM you already collect and you have both halves: an alert when the site breaks, and evidence about who it was slow for. The rest of the monitoring concepts section covers the terms these two rest on.