Synthetic Monitoring: The Three Rungs Explained
Synthetic monitoring generates traffic on a schedule so failures surface at 3 am with no users online. Here are its three tiers and what each one costs.
Synthetic monitoring is the practice of generating traffic against a service on a schedule, instead of waiting for real users to generate it. It runs a fixed request or a scripted journey from a known location and checks the answer against an expectation. Its main use is catching a failure at three in the morning, when nobody is looking.
How does synthetic monitoring work?
A probe somewhere on the internet runs a defined transaction at a defined interval, then compares what came back to what should have come back. The transaction might be a single HTTP request, a chain of API calls with assertions between them, or a headless browser walking a checkout. The comparison produces a verdict and a set of timings.
Two properties define the category. The traffic is manufactured, so results exist even at zero real usage. The location is chosen, so a failure carries geography with it, which passive measurement cannot give you.
The three rungs of the ladder
Vendors sell this as one product, but it is really three tiers with very different costs. Knowing which rung a check sits on tells you how much it costs to run and how often it will lie to you.
| Rung | What it does | Typical interval | Failure modes it catches |
|---|---|---|---|
| Availability check | One request, assert status and body | 30 to 60 seconds | DNS, TLS, routing, process death, hard errors |
| API transaction | Several calls, assert on each response | 1 to 5 minutes | Broken contracts, auth expiry, bad data |
| Scripted browser | Drives a real browser through a flow | 5 to 15 minutes | Broken front-end builds, third-party scripts, checkout bugs |
The first rung catches most outages. The second catches most regressions. The third catches the expensive, embarrassing kind, and costs enough per run that few teams point it at more than a handful of journeys. Start at the bottom and climb only when the rung below stops finding things.
Synthetic monitoring versus real user monitoring
Real user monitoring records what actual visitors experienced, from their own browsers or devices. The two techniques answer opposite questions and neither replaces the other.
| Synthetic | Real user | |
|---|---|---|
| Traffic source | Generated by a probe | Real visitors |
| Works at 3 am with no users | Yes | No |
| Covers every device and network | No, only the ones you configure | Yes, whatever people use |
| Gives a clean baseline | Yes, identical conditions each run | No, conditions vary constantly |
| Needs code in the page | No | Yes |
Synthetic testing gives you a controlled experiment, repeated forever. Real user data gives you the messy truth with no control. We prefer to alert on the controlled version and prioritise from the messy one. A page load that is slow for everyone is a different problem from one that is slow only on a 3G connection in one country.
What an external probe fleet covers
The bottom two rungs need no agreement from your application at all. A probe resolves your DNS record, completes a TLS handshake, sends a request and reads the answer, exactly as a browser would. A surprising share of real incidents live on that path. An expired certificate, a DNS record left pointing at a decommissioned host, a firewall rule that quietly began dropping one region: each is invisible from inside the application.
This rung of synthetic monitoring reports timings as a waterfall rather than one number. DNS resolution, TCP connect, TLS handshake, time to first byte and content download are each reported separately, so a slow result can be attributed before anyone opens a log.
Run the same check from several of the six probe regions available as of September 2026, and a regional routing failure stops looking like a global outage. The API reference has the fields, and blackbox monitoring covers the outside-in stance in depth.
There is an honest limit here. Nothing measured from outside sees queue depth, garbage collection pauses or a memory leak in a worker. Those need instrumentation inside the process, which is APM territory, and a probe fleet is not a substitute for it.
When is the scripted browser rung worth it?
Reach for it when the failure you fear is invisible to an HTTP request. Think of a checkout that breaks when a payment widget changes its API. Or a login that fails only after a front-end deploy, or a search box wired to the wrong endpoint. None of those change a status code. Tools built on Playwright, like Checkly, exist for exactly this.
The cost is not only money. Browser scripts break when your own markup changes, so they need maintenance on every release, and a flaky script trains a team to ignore alerts faster than almost anything else. One well-kept journey beats a dozen neglected ones.
Where the term gets stretched
The phrase is older than the current vendor category. Wikipedia traces it back to scripted transaction monitoring, and observability platforms now fold ping, DNS and traceroute checks under the same banner, as Grafana Cloud does. That is fair: an ICMP check is manufactured traffic on a schedule, so it meets the definition.
The stretch to watch is the claim that a synthetic check proves an experience is good. It proves one path worked once, from one place, for one configuration. Everything else is inference.
Treat synthetic monitoring as a smoke alarm rather than a diagnosis. Put an availability check on every public endpoint, add API assertions where the contract matters, and keep scripted browsers for the two or three journeys that pay your bills. The free plan covers 10 monitors at a one-minute interval as of September 2026, which is enough to cover the first rung properly.
FAQ
It means generating traffic against a service on a schedule rather than waiting for real visitors. A probe in a known location runs a fixed request or a scripted journey, compares the response to an expectation, and records timings. Because the traffic is manufactured, the data exists even when nobody is using the service.
Synthetic traffic is generated by probes you configure, so conditions repeat identically and results exist at any hour. Real user monitoring records what actual visitors experienced on their own devices and networks, which is messier but complete. Use the first for alerting and baselines, and the second for deciding what to fix.
Yes. A scheduled HTTP request with an assertion on the status code is the simplest synthetic check there is, and it catches the majority of real outages: DNS failures, expired certificates, routing problems and dead processes. The more elaborate tiers add API chains and scripted browsers on top of the same idea.
Availability checks usually run every 30 to 60 seconds, because they are cheap and detection time matters. API transactions fit better at one to five minutes. Scripted browser journeys cost enough per run that 5 to 15 minutes is typical, and they are reserved for the handful of flows that directly carry revenue.
No. A probe measures what a client on the internet sees, which covers DNS, TLS, routing and response correctness. It cannot see queue depth, garbage collection pauses or a memory leak inside a worker process. Those need instrumentation running in the application itself, so the two tools complement each other.
Related reading
- Blackbox Monitoring: What the Outside View Sees - Blackbox monitoring tests a service from outside with no access to its internals, which is how you catch DNS, TLS and routing failures.
- Ping Monitoring: What ICMP Checks Prove and Miss - Ping monitoring tells you an address answers ICMP, nothing more. Here is how echo requests work, what they hide, and when a TCP check is the better signal.