# Synthetic Monitoring vs Real User Monitoring (RUM) > Synthetic monitoring runs scripted checks on a schedule; real user monitoring (RUM) measures actual visitors. How they differ and why most teams use both. Source: https://loadster.com/guides/synthetic-monitoring-vs-real-user-monitoring/ ## Two Ways to Monitor Website Performance There are two basic ways to find out how your site is performing in production. You can send your own test traffic and measure what happens, or you can measure the traffic that real visitors are already sending. The first approach is **synthetic monitoring**, sometimes called active monitoring. Scripted bots run checks against your site or API on a schedule, from locations outside your infrastructure, and alert you when something fails or slows down. Our [synthetic monitoring guide](https://loadster.com/guides/synthetic-monitoring/) covers it in depth. The second approach is **real user monitoring (RUM)**, a form of passive monitoring. A JavaScript snippet on your pages records timings and errors from each visitor's browser and reports them back for analysis. Both approaches measure performance, but they answer different questions and fail in different ways. This guide walks through how each one works, where each one falls short, and how teams usually combine them. Loadster is a [synthetic monitoring](https://loadster.com/synthetic-monitoring/) platform and doesn't do real user monitoring, so we'll be clear about where a RUM tool is the better fit. ## What is Real User Monitoring (RUM)? Real user monitoring collects performance data from the browsers of your actual visitors. You add a small script to your pages, and as each visitor loads a page and interacts with it, the script reports what it measured to a collector. The collector aggregates millions of these reports into dashboards and percentiles. A typical RUM setup records page load timings like Time to First Byte (TTFB) and First Contentful Paint (FCP), the Core Web Vitals (Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift), JavaScript errors, and context like browser, device type, country, and connection speed. You can buy RUM as part of a commercial observability suite, or build a lightweight version yourself. Google's open source web-vitals library is a tiny script that measures the Core Web Vitals in real users' browsers, and you can send its output to whatever analytics backend you already have.[^1] Google's own guidance draws the line clearly: lab measurement is essential, but it isn't a substitute for field measurement, because real performance depends on each user's device, network, and how they interact with the page.[^2] RUM is how you get that field data for your own site. ## How Synthetic Monitoring Works Synthetic monitoring flips the model around. Instead of waiting for visitors, a monitoring service runs a script against your site on a fixed schedule, such as every minute or every five minutes. The script might load a single page, call an API endpoint, or walk through a complete user journey like logging in and checking out. Each run either passes or fails against the checks and thresholds you've defined. When a run fails, the service opens an incident and alerts your team, usually with a trace or screenshot showing which step went wrong. Because the bot does the same thing from the same locations every time, synthetic monitoring gives you a stable baseline. A response time change in a synthetic monitor is much more likely to be a real change in your system than a change in who happened to visit that hour. ## Synthetic Monitoring vs RUM: Key Differences The two approaches differ along a few dimensions that matter in practice. **Where the traffic comes from.** Synthetic monitoring creates its own traffic. RUM relies on real visitors, so it has nothing to report on pages nobody visits, and very little to report overnight or on a low-traffic staging site. **When you find out.** A synthetic monitor can catch a broken checkout flow at 3 a.m. before the first customer of the day tries it. RUM reports a problem after real users have already run into it, although with high traffic that might only take seconds. **Coverage.** RUM covers every page that gets traffic, including ones you'd never think to script. Synthetic monitoring only covers the flows you've scripted, so an unmonitored page can break without any alert. **Consistency.** Synthetic checks run under controlled conditions, which makes trends and regressions easy to spot. RUM data is naturally noisy, because it blends fast desktop connections with slow phones on congested networks, and the mix changes throughout the day. **Realism.** RUM is the real thing: real devices, real networks, real third-party scripts, real user behavior. Synthetic checks approximate a user, and a bot in a data center typically has a faster connection than most of your visitors. **Complete outages.** If your site is completely down, the RUM snippet never loads, so a RUM tool might simply see a drop in traffic rather than an error. A synthetic monitor sees the failure directly and alerts on it. **Interactivity metrics.** Some metrics need a human. Interaction to Next Paint measures how quickly the page responds to real input, and Google notes that tools loading pages without a user can't measure it.[^2] Synthetic browser monitors are good at load-time metrics like TTFB, FCP, LCP, and CLS, but INP really belongs to RUM. ## Active vs Passive Monitoring You'll often see synthetic monitoring and RUM described as active and passive monitoring. The terms are broader than websites, but the idea is the same. **Active monitoring** injects test traffic and checks the response. Synthetic monitors, API health checks, and ping checks are all active monitoring. The advantage is that you control exactly what gets tested and when. **Passive monitoring** observes traffic that already exists. Real user monitoring is passive monitoring in the browser. Server access logs, application performance monitoring (APM) traces, and network flow analysis are other forms of passive monitoring on the backend. Active monitoring is how you find out quickly that something is broken. Passive monitoring is how you find out how many people were affected, and whether a problem you can't reproduce is real. ## What Synthetic Monitoring Catches That RUM Misses Synthetic monitoring is usually the better tool for these situations: - **Outages during quiet hours.** No traffic means no RUM data, but a scheduled monitor keeps checking. - **Broken multi-step flows.** A [synthetic transaction monitor](https://loadster.com/guides/synthetic-transaction-monitoring/) that logs in and checks out fails as soon as checkout breaks, while RUM might just show fewer visitors reaching the confirmation page. - **API failures.** [API monitoring](https://loadster.com/guides/api-monitoring/) checks endpoints that have no browser and no RUM snippet at all. - **Regional problems.** Running the same check from several locations can show a DNS, CDN, or routing issue that only affects one region. - **Pre-launch and staging environments.** You can monitor a new feature or a staging environment before real users arrive. - **Third-party dependencies.** A scripted flow that exercises your payment provider or login service catches a vendor outage on a schedule rather than waiting for complaints. ## What RUM Catches That Synthetic Monitoring Misses Real user monitoring is usually the better tool for these: - **The long tail of devices and networks.** If your site is fine on a fast laptop but painful on mid-range Android phones, RUM will show it and a synthetic monitor in a data center probably won't. - **Pages you didn't think to script.** RUM covers every page with the snippet, including a slow product page buried deep in your catalog. - **Interaction responsiveness.** INP and other interaction-driven metrics depend on real user input. - **Business correlation.** RUM data can be tied to conversion rates, bounce rates, or specific customer segments, which helps prioritize performance work. - **Problems that only appear at real scale.** Some issues only appear with real traffic patterns. If you want to rehearse heavy traffic before it happens, that's a job for [load testing](https://loadster.com/guides/load-testing/) rather than monitoring. ## Using Synthetic Monitoring and RUM Together Most mature teams use both, because each one covers the other's blind spots. A fairly common setup looks like this: 1. **Synthetic monitors on the critical flows.** Uptime checks on key pages and endpoints every minute or few minutes, plus a transaction monitor for each flow that would hurt if it broke (signup, login, search, checkout). 2. **Alerting from synthetic monitors.** Because synthetic results are consistent, they make good alert triggers with relatively few false alarms. 3. **RUM for trends and investigation.** RUM dashboards show how real visitors' performance changes over time and how widespread an incident was. 4. **Feedback in both directions.** When RUM shows a slow page or a struggling flow, add a synthetic monitor for it. When a synthetic monitor alerts, check RUM to see how many real users were affected. If you're starting from nothing, synthetic monitoring is usually the quicker win for catching outages, since it works on day one regardless of traffic. Real user monitoring becomes more valuable as traffic grows and you start caring about the full range of experiences rather than just whether the site works. ## Synthetic Monitoring with Loadster Loadster runs synthetic monitors using the same script types as its load tests: Protocol Bots for lightweight HTTP and API checks, Browser Bots that drive real Chrome browsers through user journeys, and Playwright Test scripts for teams who already write Playwright. Browser-based monitors capture TTFB, FCP, LCP, and CLS on every cycle, so you get a consistent synthetic baseline for the load-time metrics that RUM tools also report. Monitors run from 8 dedicated locations across 5 continents, open incidents when a cycle fails, and alert your team by email, SMS, phone call, Slack, PagerDuty, Opsgenie, or webhooks. Loadster doesn't do RUM, so if you want field data from real visitors, pair it with a RUM product or the web-vitals library. To see how it works, visit [Synthetic Monitoring](https://loadster.com/synthetic-monitoring/) or read the broader [synthetic monitoring guide](https://loadster.com/guides/synthetic-monitoring/). A free account comes with 50 units of Loadster Fuel, which is enough to run a few monitors with no credit card required. ## Frequently Asked Questions ### What is real user monitoring (RUM)? Real user monitoring measures the experience of the actual people using your site. A small JavaScript snippet on each page reports timings like page load, Core Web Vitals, and JavaScript errors from every visitor's browser back to a collector, so you can see performance across real devices, networks, and locations. ### What is the difference between synthetic monitoring and real user monitoring? Synthetic monitoring generates its own traffic with scripted bots on a schedule, so it tests the same flow the same way every time, even when nobody is on the site. Real user monitoring passively records what actual visitors experience, so it reflects real conditions but only for pages people visit, and only after they've been affected. ### What is the difference between active and passive monitoring? Active monitoring sends its own test traffic to a system and checks the result, which is what synthetic monitoring does. Passive monitoring observes traffic that already exists, such as real user monitoring in the browser or analyzing server logs. Active monitoring finds problems before users do; passive monitoring shows how widespread a problem actually was. ### Should I use synthetic monitoring or RUM? Most teams end up using both. If you can only start with one, synthetic monitoring is usually the better first step for catching outages and broken flows quickly, since it doesn't depend on traffic. Add real user monitoring once you want to understand the full range of performance your visitors actually get. ### Does Loadster do real user monitoring? No. Loadster does synthetic monitoring with Protocol Bots, Browser Bots, and Playwright scripts, and it doesn't collect data from your real visitors. Many teams pair Loadster monitors with a separate RUM tool, or with Google's open source web-vitals library feeding their own analytics. --- **Next Steps:** Ready to set up your first synthetic monitor? Start with [Synthetic Monitoring](https://loadster.com/synthetic-monitoring/) and monitor your most important flow with a Browser Bot, Protocol Bot, or Playwright script. #### Related Guides * [Synthetic Monitoring: Tools and Techniques](https://loadster.com/guides/synthetic-monitoring/) — the full primer on how synthetic monitoring works. * [Synthetic Transaction Monitoring](https://loadster.com/guides/synthetic-transaction-monitoring/) — monitoring multi-step user journeys like login and checkout. * [API Monitoring](https://loadster.com/guides/api-monitoring/) — synthetic checks for API uptime, response time, and correctness. * [Front End vs Back End Performance](https://loadster.com/guides/front-end-vs-back-end-performance/) — where page load time actually goes. [^1]: [Google's web-vitals library on GitHub](https://github.com/GoogleChrome/web-vitals) describes a tiny, modular, Apache 2.0 licensed library for measuring LCP, INP, CLS, FCP, and TTFB on real users. [^2]: [Google's Web Vitals overview on web.dev](https://web.dev/articles/vitals) explains that lab measurement isn't a substitute for field measurement, and that tools loading pages in a simulated environment without a user can't measure INP.