Synthetic monitoring sends scripted checks to your site on a schedule from known locations, so it works with zero traffic and catches outages at 3am. Real user monitoring (RUM) records what actual visitors experience in their browsers, so it shows real devices, networks and pages. Synthetic catches total outages RUM cannot see; RUM catches real-world slowness synthetic never scripted.
What is synthetic monitoring?
Synthetic monitoring means generating traffic on purpose to test a system. A monitoring service sends a request, or drives a scripted browser, against your site on a fixed schedule from machines it controls, then grades the result against rules you set: the status code, the content of the page, the response time, the certificate, or whether a multi-step flow such as login still completes.
The word synthetic is the point. The traffic is not from a customer; it is manufactured, so it is identical every time. The same request from the same place at the same interval makes results comparable from one minute to the next, and it keeps arriving whether or not anyone is using the product.
- Uptime checksThe simplest form: a request to a URL or port every minute or so, asserting that it answers correctly and in time.
- API checksRequests to the endpoints your clients call, with authentication headers and assertions on the response body, sometimes chained across several steps.
- Scripted browser checksA headless browser follows a user journey, such as search, add to cart and pay, and fails if a step breaks or takes too long.
- Protocol checksDNS, TLS, TCP, ping and similar checks below the application, which tell you which layer failed.
What is real user monitoring (RUM)?
Real user monitoring collects measurements from the people actually using your site. A small JavaScript snippet in your pages (or an SDK in a mobile app) reads timing data the browser already records, such as navigation and resource timings and Core Web Vitals (Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift), along with JavaScript errors, and sends it to a collector.
Because the data comes from real sessions, it carries the full mess of the real world: old phones, slow mobile networks, browser extensions, distant countries, pages nobody thought to script. RUM answers "what did our users actually experience?", which no scripted check can.
Web performance people use the same split under other names. Lab data comes from a controlled test, like a synthetic check or a Lighthouse run. Field data comes from real visits, like RUM or the Chrome UX Report. Search engines and performance budgets increasingly care about field data, because that is what users feel.
What does synthetic monitoring catch that RUM misses?
- Total outagesWhen the site does not load at all, the RUM script never runs, so nothing is reported. A complete outage looks like a quiet period. A synthetic check records a failure on its next run.
- Problems before the traffic arrivesA broken deploy at 3am, a certificate that expires on a Sunday, or a DNS change that breaks resolution overnight are caught by a schedule, not by the first unlucky morning visitor.
- Low-traffic pathsThe password reset page, the annual billing flow or an admin API may see a handful of visits a day. Too few samples for RUM to show a trend; one synthetic check a minute is plenty.
- Things that are not pagesAPIs, webhooks, background job endpoints, TCP services, DNS records and certificates have no browser to run a RUM script in.
- A clean baselineBecause the check never changes, a jump in its response time points at your system, not at a change in who happened to visit.
What does RUM catch that synthetic monitoring misses?
- Slowness on real devices and networksA page that loads quickly from a data centre can be slow on a mid-range phone on a congested mobile network. Synthetic checks run on fast machines with good connections.
- Journeys nobody scriptedYou script the paths you know matter. RUM covers every page that gets traffic, including the one a marketing campaign suddenly sent thousands of people to.
- Client-side errorsA JavaScript error that only happens in one browser version, or a third-party script that blocks rendering for some visitors, appears in RUM error reports and rarely in a scripted check.
- Distribution, not a single numberRUM shows percentiles across all users, so you can see that the median is fine while the slowest tenth of visits is not.
- Network-specific problemsIf visitors on one ISP or in one country fail or crawl, RUM can break results down by those dimensions, as long as some of the page still loads and reports.
The most important asymmetry: RUM goes quiet when things are worst. If the page cannot load, or the RUM collector itself is unreachable, the dashboard shows a traffic drop that looks the same as a quiet hour. Never rely on RUM alone to tell you the site is down.
Cost: how the two are usually priced
The pricing models differ, and that shapes how each grows with your business. Check current prices with each vendor; the structure is what matters here.
- Synthetic monitoring is usually priced by the number of checks: how many monitors, how often they run and, for some vendors, from how many locations. The cost is predictable and does not change with traffic.
- Scripted browser checks cost more per run than simple HTTP checks, because each one starts a real browser, so most teams run them less often and on fewer journeys.
- RUM is usually priced by volume: page views, sessions or events. The bill rises with traffic, which is why many teams sample, recording only a share of sessions.
- RUM also has a cost inside your product: the script adds bytes and work to every page, so keep it small and load it without blocking rendering.
For a small site with modest traffic, synthetic monitoring is the cheaper way to know whether the site is up. RUM starts to pay for itself when you have enough traffic that real-world performance moves revenue and you have someone with time to act on what it shows.
Privacy: what each collects
Synthetic monitoring collects data about your system, not about people. The requests come from the monitoring service, the responses are your own pages, and no visitor is involved. That makes it easy to run under almost any privacy policy, provided your checks use a dedicated test account rather than a real customer's credentials.
RUM collects data from your visitors' devices, which makes it personal data processing in many jurisdictions. IP addresses, device details, the pages someone visited and session identifiers can all identify a person, especially in combination. Before you add RUM:
- Check whether your privacy notice covers it and whether your consent setup needs to gate it, which depends on the law that applies to your visitors and on how the tool stores identifiers.
- Collect the minimum: timings and error types rather than full URLs with query strings, and never form contents, which can contain passwords or payment details.
- Mask or drop personal data in URLs and error messages before they leave the browser.
- Know where the vendor stores the data and add it to your list of processors.
- If you use session replay, treat it as a separate, more sensitive decision: it records what people do on the page, not just how fast it loaded.
Where uptime checks fit
Uptime monitoring is the most basic layer of synthetic monitoring, and for most teams it is the first one to set up. It answers one question continuously: can the outside world reach this service and get a correct answer right now? Everything else, scripted journeys, performance budgets and RUM dashboards, builds on knowing that.
Three things make uptime checks trustworthy enough to page someone. They run from outside your infrastructure, so they fail when your users would. They assert on something meaningful, such as a keyword on the page or a field in an API response, rather than accepting any 200. And they confirm a failure from more than one location before alerting, so a network blip near one checker does not wake anyone up.
SutramX is synthetic monitoring: uptime, API, SSL, DNS, port, heartbeat and MCP server checks, with alerting, on-call and status pages. It does not do real user monitoring. The Free plan checks 50 monitors every 3 minutes; the fastest interval by plan is 15 seconds on Pro, 30 seconds on Growth, 60 seconds on Starter and 3 minutes on Free. If you need RUM, pair SutramX with a dedicated RUM tool.
When should you use both?
A sensible order for most teams:
- 1. Start with synthetic uptime checksCover the endpoints whose failure costs the most: the home page, login, checkout and the main API. This tells you when you are down, which RUM cannot.
- 2. Add API and journey checksAssert on response bodies, check authenticated routes and script the one or two flows that make money. This tells you when you are broken but technically up.
- 3. Add RUM when performance matters to revenueOnce you have steady traffic and someone who will act on the data, RUM shows how real users experience speed and errors across devices and regions.
- 4. Connect the twoWhen RUM shows a slowdown in one region, add a synthetic check there to get a clean baseline. When a synthetic check fails, look at RUM to see how many real users were affected.
The two are complementary because their blind spots do not overlap. Synthetic monitoring is reliable and narrow; RUM is broad and goes silent in a total outage. Running both is not redundancy, it is coverage.
Synthetic vs RUM FAQ
Is synthetic monitoring the same as uptime monitoring?
Uptime monitoring is one kind of synthetic monitoring. Synthetic monitoring also includes API assertions, scripted browser journeys and protocol checks such as DNS and TLS. All of them use generated traffic on a schedule rather than real visitors.
Can RUM replace uptime monitoring?
No. RUM needs a page to load and a script to run before it can report anything, so a complete outage produces no data. It also cannot see APIs, background services or certificates. You still need an outside check to know the service is reachable.
Does synthetic monitoring affect my analytics?
Simple HTTP checks do not run JavaScript, so they do not trigger most analytics tags. Scripted browser checks can. Most monitoring services send an identifiable user agent; filter it out of analytics, and exclude synthetic traffic from RUM data so it does not skew real-user numbers.