What is synthetic monitoring, and how is it different from real-user monitoring?

Synthetic monitoring sends scripted requests from outside on a schedule; real-user monitoring measures actual visitors. Here is what each catches, what each misses, and why you want both.

Synthetic monitoring is the practice of sending scripted, repeatable requests to your service from outside, on a schedule, and judging the responses against what you expect. The requests are synthetic in the sense that no real customer made them — a probe did — which is exactly what makes them useful: they run at 3 a.m. on a Sunday when nobody is using the product, and they run the same way every time, so a change in the result is a change in the service.

Real-user monitoring (RUM) is the other half: instrumenting the pages or apps real people use and collecting what happened to them — load time, errors, the route they took. It tells you what customers experienced; it cannot tell you anything when there are no customers, and it cannot tell you *why* without a lot of context.

What synthetic checks catch

• Outages before customers report them. A check every 30 seconds from outside your network notices a dead load balancer, an expired certificate or a DNS change minutes before the first support ticket.
• Regressions in a specific path. An API journey — sign in, create, read, delete — proves the whole flow works, not only that the homepage returns 200.
• Regional problems. The same check from several locations shows a CDN edge or a transit route failing for one part of the world while the rest is fine.
• Slow drift. Because the request is identical each time, the response-time series is clean enough to baseline, so a 40% slowdown over a week is visible where it would hide in noisy real-user data.

What they miss

• Things the script does not do. If the checkout has twelve steps and the probe runs three, steps four to twelve are unmonitored.
• Device, browser and network variety. A probe in a data centre on a fast link does not experience a 3G connection in a lift.
• Content that depends on who you are. A synthetic user is one user; a bug that hits only accounts with more than 10,000 records is invisible to it.

Choosing what to check

The useful rule is *one synthetic check per promise you make to customers*. If you promise the API is up, check the API with an assertion on a real response. If you promise checkout works, run a journey through checkout. If you promise the certificate will not expire, watch the certificate. Then let real-user data tell you which promises you have not made yet.