One asks the app a question every few minutes. The other listens to what the app does to real people. They disagree constantly, and the disagreement is the information.
Synthetic monitoring requests your site or API from outside, on a schedule, from known locations, and records whether it responded, how fast and with what — it is active, repeatable and works at 3 a.m. with no visitors. Real user monitoring (RUM) runs in your actual visitors' browsers and records what happened to them — errors, failed requests, slow pages — it is passive, covers every device and network you did not think of, and only sees what users do. Synthetic answers "is it up and is it drifting"; RUM answers "is it working for people". A site can be green on every synthetic check while a JavaScript error breaks checkout for everyone on Android (RUM sees it), and RUM can be silent at night while the database is down (synthetic sees it). Small teams tend to have one and assume it covers the other. This guide sets out what each catches, the privacy line RUM must respect under the DPDP framework and generally, and a minimal setup with both. Facts checked 14 October 2026.
Misses: anything that happens only in a real browser session — a JavaScript error after a click, a request that fails only for logged-in users, a layout that is unusable on a particular phone.
Misses: an outage with no visitors (nothing to report), the cause (RUM sees the symptom in the browser, not the failing query), and anything behind a login that users do not reach because the login itself is broken.
| Synthetic red, RUM quiet | Outage during low traffic, or a failure before the page loads (DNS, TLS, 5xx). Act on synthetic. |
|---|---|
| Synthetic green, RUM loud | The app is up; a flow is broken in the browser — usually after a deploy or a third-party change. Act on RUM; check the deploy timeline. |
| Both red | A real outage users are hitting. Incident; status page; one owner. |
| Both green, users complaining | A flow neither covers — add a synthetic check for it, and confirm RUM is installed on that page. |
This matrix is why "the application is up but users see errors" is the commonest small-team incident: only one side was being watched.
RUM runs in your users' browsers, so it is personal-data processing. For monitoring purposes you need the error, the page, the browser type and a count — not the person. The defensible configuration: no cookies and no persistent identifiers; query strings stripped before anything is sent (they carry tokens and emails); personal data patterns redacted server-side; no session replay by default; events grouped by error fingerprint per hour rather than stored per user; short retention. A RUM tool that offers "see exactly what the user did" is a different product with a different legal footing — consent, notice, retention — and a small team rarely needs it. The security checklist questions apply to the RUM vendor too.
Where this sits in the bigger picture: observability vs monitoring and logs vs monitoring. Synthetic and RUM are the monitoring layer; logs and traces are what you open once one of them has told you something is wrong.
| Synthetic | Active, scheduled, external, repeatable; no traffic needed |
|---|---|
| RUM | Passive, in real browsers, real devices and networks; needs traffic |
| Synthetic catches | Downtime, latency drift, certificate expiry, broken endpoints, dependency outages |
| RUM catches | JavaScript errors, unhandled rejections, failed browser requests, device-specific problems |
| Synthetic misses | Broken flows inside a browser session |
| RUM misses | Outages with no visitors; root cause; anything behind a broken login |
| Privacy for RUM | No cookies, query strings stripped, server-side redaction, fingerprint grouping, no replay by default, short retention |
| Minimal setup | Synthetic on app + dependencies + SSL; one RUM script tag; deploys and vendor feeds on the timeline |
Synthetic monitoring sends scheduled requests to your site or API from outside and records availability, response time and content; it works regardless of traffic. Real user monitoring runs in actual visitors' browsers and records errors, failed requests and performance as they experienced them; it only sees what users do. Synthetic answers whether the app is up and drifting; RUM answers whether it is working for people.
For anything users depend on, yes. Synthetic cannot see a JavaScript error that breaks a button while the server is healthy, and RUM cannot see an outage when nobody is visiting or tell you the cause. The two disagree often, and the disagreement tells you where the problem is.
It processes personal data because it runs in users' browsers, so configure it for monitoring rather than profiling: no cookies or persistent identifiers, query strings stripped, personal data redacted on the server, errors grouped by fingerprint rather than stored per user, no session replay by default, and short retention. That configuration needs a notice but is defensible; session-replay products need consent.
Synthetic should drive alerts, because its failures are confirmed, repeatable and independent of traffic. RUM should alert only when a new error group appears or an existing one spikes, and otherwise serve triage: how many sessions, which pages, which browsers.
Yes, with scripted checks that log in and step through a flow, if you have an engineer to write and maintain them. Without one, check the login endpoint synthetically and rely on RUM for what happens after login.
Synthetic checks every few minutes on the app, its login endpoint and each dependency API, plus a daily certificate check with confirmation before alerting and one owner alerted; a single RUM script tag capturing errors, rejections and failed requests; and deploys and vendor status feeds on the same timeline so incidents are explained.
Merik's Digital Operations is both halves in one place. Synthetic: each registered website, web app or API is checked from the outside every few minutes for availability, response time and HTTP status, with a 14-day baseline per monitor, early warnings on drift (risk score, confidence score, evidence), and confirmed failures opening an incident assigned to the owner and alerted once with quiet hours. Real-user: the browser SDK is one script tag that reports JavaScript errors, unhandled promise rejections and failed requests, grouped by fingerprint per hour, with no cookies, query strings stripped and personal data redacted server-side — the privacy configuration described above. Deploys from GitHub and Vercel webhooks and vendor status feeds sit on the same incident timeline.
Merik does not run scripted logged-in flows, session replay or web-vitals dashboards; it is the minimal setup for a team without an ops person, inside the workspace that runs the rest of the business. See Digital Operations.
Free, set up for you, every module included — see what the free workspace includes
Uptime 100%, users unhappy — both true. Closing the gap between server health and experience.
The server said 200. The page broke anyway. Seeing the failures uptime checks can't.
Monitoring says something is wrong; observability says why. The two, untangled.
Request your free company workspace and bring employees, attendance, leave, payroll and tasks together.