Two teams describe their monitoring setup the same way, "we use synthetic and RUM", and mean completely different things. One has a scheduled uptime check from three regions and a JavaScript snippet that records load times. The other has a multi-step browser flow that logs in every minute and a full session-replay pipeline. Both are valid. Neither is what the other team would build if they started over.
Synthetic monitoring and real user monitoring (RUM) are complementary, not competing. They answer different questions and fail in different ways. This post is about which one you actually need first, when to add the other, and what each is useless at.
What Synthetic Monitoring Is
Synthetic monitoring is the scheduled, external execution of a defined script against your site or API, pretending to be a user, on a fixed cadence, from outside your infrastructure. The simplest synthetic check is an HTTP request that asserts a 200 response. The most sophisticated is a headless browser that logs in, navigates a checkout, and asserts the order confirmation page renders correctly.
The defining characteristics:
- Proactive: checks run on a schedule whether or not real users are active. You catch outages at 3am before anyone sees them.
- External: runs from infrastructure you don't control, so when your data center is unreachable, the monitor still works.
- Deterministic: the same script runs every time, so a failure means something changed on your side, not the user's.
- Pre-launch capable: you can monitor a flow before any real users exist.
Read the complete guide to uptime monitoring for the full breakdown of synthetic check types.
What Real User Monitoring Is
Real user monitoring (RUM) instruments your actual users' browsers and records what happens when they load your site. Typically a small JavaScript snippet captures page load timings, errors, navigation events, and (in fuller implementations) full session recordings or interaction traces.
The defining characteristics:
- Reactive: only collects data when real users are active. Quiet at 3am, noisy at peak.
- In-context: captures the exact device, network, and geography of each session, including bad mobile networks and aging browsers you'd never include in a synthetic script.
- Statistical: useful at scale. A handful of sessions is noise; tens of thousands a day surface meaningful patterns.
- Privacy-loaded: you're collecting data on real people, which means cookie banners, GDPR, CCPA, and an honest review of what you actually need to retain.
Side-by-Side: What Each One Catches
| Synthetic | RUM | |
|---|---|---|
| Detects an outage at 3am | Yes, within one interval | No, no users, no data |
| Tells you how slow real users are | Inferred only | Yes, with percentiles by geography and device |
| Works before launch | Yes | No, needs real users |
| Catches browser-specific JavaScript errors | Partially (only browsers you script) | Yes, including ones you'd never test |
| Verifies an SLA from outside | Yes, that's its job | No, measurement depends on user traffic |
| Reveals slow mobile networks in specific countries | No | Yes |
| Privacy / GDPR overhead | None | Significant |
| Cost at small scale | Low fixed cost | Per-session, often unpredictable |
| Cost at large scale | Linear with check count | Can balloon with traffic |
Read it as a checklist: synthetic answers "is it working right now?", RUM answers "what are real users experiencing?". You cannot substitute one for the other.
When Synthetic Is Enough On Its Own
Most teams don't need RUM. You probably don't either if any of these are true:
- You're below ~10,000 monthly active users. RUM at that scale produces too much noise relative to signal to be worth the privacy overhead.
- Your traffic is heavily concentrated in business hours. Synthetic checks during off-peak hours give you the same outage detection RUM would, without the cost.
- You're an agency or freelancer managing client sites. Your obligation is uptime and an SLA, both of which are synthetic territory. See website monitoring for agencies.
- You haven't fully solved your synthetic monitoring yet. Adding RUM on top of incomplete synthetic coverage is solving a more advanced problem before the basic one.
For these teams, the right setup is multi-region synthetic checks with consensus alerting, layered with keyword and JSON assertions on the pages and APIs that drive revenue. That covers 95% of what most businesses need.
When RUM Becomes Worth the Trouble
RUM starts paying off when one of these is true:
- Performance is the product. Media sites, ecommerce checkout flows, B2B SaaS dashboards, anywhere a 500ms slowdown loses real money and you need to prove it.
- Your audience is globally distributed. Synthetic from 10 regions still doesn't capture the slow mobile network in Lagos or the corporate proxy in Frankfurt that's adding 800ms to every request. RUM does.
- You're optimizing Core Web Vitals seriously. Google's field data uses real users. If you're chasing LCP/INP/CLS scores, lab data alone won't get you there.
- You're large enough to have a performance team. RUM data is only useful if someone is actually looking at it. Tools that ingest data nobody reads aren't observability, they're billing.
The honest truth is that most teams adopt RUM too early, find the data overwhelming, and quietly stop looking at it. Don't be that team.
The Hybrid Approach
If you do end up with both, draw a clean division of responsibilities:
- Synthetic owns uptime, SLA, and incident detection. Anything that needs to wake someone up runs through synthetic monitoring. The signal is binary and decisive.
- RUM owns performance budgets and UX trends. Anything that's about gradual regression or geographic experience goes through RUM. The signal is statistical and best looked at weekly, not by alert.
Mixing the two is where alert fatigue is born. If a RUM percentile crosses a threshold, that's a Monday-morning ticket, not a Saturday-night page. If a synthetic check fails three times in a row, that's a page now. Different signals, different channels.
How Synthetic Checks Become "User-Like"
The gap between synthetic and RUM narrows considerably when synthetic checks stop being single-endpoint pings. Modern synthetic monitoring can:
- Run multi-step browser flows. Log in, navigate, submit a form, assert a confirmation, the same workflow a real user would. This is where most "is checkout broken right now?" questions get answered.
- Run from multiple geographic regions. Three to five regions give you a usable picture of global availability without RUM's privacy overhead. See global uptime monitoring.
- Assert on JSON payloads and page content. A 200 OK on a search page that returns zero results is still an outage. Keyword and JSON assertions catch what status codes miss.
- Schedule realistic intervals per check. Critical paths every 30 seconds, marketing pages every five minutes, the same way RUM weighs different traffic naturally.
For most teams, a well-configured synthetic setup is closer to RUM than they expect, at a fraction of the operational cost.
Putting It Together
Start with synthetic. Get multi-region checks, JSON and keyword assertions, and a real alerting plan in place before you instrument a single real user. Sentinel covers all of this in one dashboard, multi-region synthetic checks, payload assertions, status pages, and uptime reports. See pricing; the free tier is 10 monitors with no credit card.
Add RUM later, if and when your scale and your audience justify it. Most teams will find that "later" never comes, and that's the right answer.