Synthetic vs Real User Monitoring: Differences and When to Use Each

There are two basic ways to know how your website is doing. You can send a robot to visit it on a schedule and record what happens, or you can record what actually happens to real visitors. The first is called synthetic monitoring, the second real user monitoring (RUM). They answer different questions, they fail in different ways, and most sites eventually want some of each. This guide explains the difference and helps you choose without overspending.

Synthetic monitoring in one paragraph

Synthetic monitoring means automated checks that run from known locations at a fixed interval. A check might request your homepage and expect a 200 status, or load a page in a real browser and click through a login flow. The robot visits whether or not anyone else does. An uptime monitor is the simplest form: an HTTP request every few minutes, plus an alert when it fails.

Common types:

• Uptime and HTTP checks. Request a URL, test status code, response time and sometimes that a keyword or JSON field is present.
• Port and protocol checks. Is TCP port 443 reachable? Does DNS resolve? Is the TLS certificate valid and not about to expire?
• Browser (scripted) checks. A headless browser performs a multi-step journey such as log in, add to cart, reach checkout. This catches broken flows that return HTTP 200 but do not work.
• API checks. Call an endpoint with a test payload and validate the response. See how to monitor API endpoints.
• Heartbeat checks. For background jobs, you watch for a signal that should arrive on schedule. See cron job heartbeat monitoring.

Real user monitoring in one paragraph

RUM collects measurements from the browsers of actual visitors. A small piece of JavaScript on your pages reads the browser's performance APIs and sends the results back: how long the page took to load, Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift, JavaScript errors, and metadata such as device type, country and connection. You see what your visitors really experienced, across all their different devices and networks.

Google also publishes field data for many sites through the Chrome User Experience Report, which is what the real-user section of the Core Web Vitals tool draws from for sites with enough traffic. That is RUM data you can read without installing anything, though it is limited to Chrome users and to sites with enough traffic to be included.

The key differences

What synthetic is good at

• Availability and fast alerting. Nothing beats a scheduled check for telling you the site is down when no one is on it.
• A stable baseline. Because the conditions are constant, a change in numbers means something changed on your side, not that your visitor mix shifted.
• Testing before there are users. Staging sites, new launches and low-traffic pages can be checked.
• Critical journeys. A scripted login or checkout test tells you the flow works even when traffic is quiet.
• Third-party dependencies. Check an API, a payment endpoint, or a DNS record you rely on.

What synthetic misses

• Real device diversity. Your robot does not have a four-year-old phone on a weak mobile signal.
• Problems affecting only a segment: one browser, one country, logged-in users with large accounts.
• The effect of personalization, A/B tests and consent banners as real people see them.
• Anything between checks. A five-minute interval cannot see a two-minute outage.

What RUM is good at

• True performance. Core Web Vitals are scored on field data, so RUM shows what Google and your users see.
• Segmentation. Break down by device, country, browser or page template to find where the pain is.
• JavaScript errors and rendering issues that never show up as an HTTP failure.
• Impact analysis. How many real users were affected, and how badly?

What RUM misses

• Total outages. If the server is down, the page never loads, so the RUM script never runs and never reports. RUM tells you about problems for visitors who got through. It cannot raise the alarm when nobody can.
• Low-traffic pages, where the sample is too small to mean anything.
• Anything before your script loads.
• Visitors who block analytics scripts.

This is the central point: RUM cannot tell you reliably that your site is down. Synthetic monitoring can. That is why monitoring starts with synthetic checks, and RUM is added to learn about experience.

When to use which

A useful rule of thumb: synthetic answers "is it working?", RUM answers "how is it for people?" Start with the first question.

Using them together

The two work best as a pair:

1. Synthetic raises the alarm. A check fails, you are alerted, you start working.
2. RUM shows the blast radius. Which users, regions and devices were affected, and for how long?
3. Synthetic reproduces the problem. From several locations, you can see whether it is global or regional. The down from where tool is useful for that.
4. RUM verifies the fix. After the fix, real-user metrics return to normal.

For performance work, use a controlled lab or synthetic test, such as the website speed test, to experiment with changes, and RUM or field data to confirm that real visitors benefit. Lab results often do not match field results, because real conditions are messier.

Free options in general terms

You can get a lot without paying:

• Free synthetic uptime monitoring. Several providers offer a free tier with a few monitors and a slower check interval. SiteDownCheck's free plan includes 3 monitors with 5-minute checks, plus SSL, domain and DNS-change alerts, keyword and JSON checks, and heartbeat monitors for cron jobs. Compare any provider's free limits against your needs.
• Free field data from Google. The Chrome User Experience Report and the Core Web Vitals report in Google Search Console give real-user data for sites with enough traffic, at no cost.
• Browser DevTools and Lighthouse. Free lab testing, and you can throttle the network and CPU to approximate a slower phone.
• Privacy-friendly or self-hosted analytics. Some web analytics tools can collect basic performance data. Check what each collects and the privacy implications before enabling it.
• The browser's own APIs. If you want to build your own RUM, the web-vitals JavaScript library from Google reports the main metrics in a few lines, and you can send them to your own endpoint.

<script type="module">
  import {onLCP, onINP, onCLS} from 'https://unpkg.com/web-vitals@4?module';
  const send = m => navigator.sendBeacon('/rum', JSON.stringify({
    name: m.name, value: m.value, page: location.pathname
  }));
  onLCP(send); onINP(send); onCLS(send);
</script>

You must provide the /rum endpoint yourself to receive and store the data, and you should consider consent requirements in your region. Pin the library version you have tested.

A sensible order of operations

1. Add synthetic uptime checks for your homepage and one important transactional page, with a keyword check.
2. Add SSL, domain and DNS-change alerts. See uptime monitoring for small business.
3. Add heartbeat monitors for backups and cron jobs.
4. Look at free field data for Core Web Vitals.
5. Only then consider a RUM tool, if you need segmentation or error tracking.

Next steps

• Start synthetic checks with the uptime monitor.
• Test speed under controlled conditions with the website speed test.
• See how real visitors experience your site in the Core Web Vitals tool.
• Watch scheduled jobs with cron monitoring.
• Run a one-off check with the website health check.

FAQ

Is synthetic monitoring the same as uptime monitoring?

Uptime monitoring is the simplest kind of synthetic monitoring. Synthetic also covers scripted browser journeys, API tests and performance checks.

Can RUM replace uptime checks?

No. If the site is down, no pages load and no RUM data is sent. You still need a scheduled external check to detect outages.

Do I need RUM for a small site?

Often not. Synthetic uptime checks and free field data from Google cover most small sites. Add RUM when you need segmentation by device or region, or error tracking.

Why do lab and field speed results differ?

Lab tests use one controlled device and network. Field data reflects many devices, connections and cache states, so it is usually slower and more varied.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.