Uptime monitoring asks whether an endpoint answered. Synthetic monitoring asks whether a user could complete a task. They sound like the same question asked at different resolutions, and they are not: each is blind to a class of failure the other catches.
What each actually does ¶
Uptime monitoring makes a request on a schedule and records the outcome. Cheap, fast, runs every minute, and easy to run from many places. It measures reachability.
Synthetic monitoring drives a real browser or a scripted sequence through a journey — sign in, search, add to basket, check out — and records whether each step worked. Expensive, slow, runs every few minutes at best, and brittle. It measures function.
What uptime monitoring misses ¶
- Anything behind the front door. A marketing homepage is static and CDN-cached; it will keep loading for hours after the database is unreachable. The partial-outage shape.
- Correct-but-wrong responses. A 200 containing an error message, an empty search result set, a maintenance page nobody gave a 503. Every one is a success to a status-code check.
- Broken client-side rendering. If the HTML arrives and the JavaScript that turns it into a page throws, the response was perfect and the page is blank.
- Authentication. Login pages render fine while the identity provider behind them is dead.
What synthetic monitoring misses ¶
- Short outages. A journey that runs every five minutes and takes ninety seconds will simply not see a two-minute failure. Uptime checks running every minute will.
- Anything outside the scripted path. It tests the journey you wrote. The outage will be in the one you did not.
- Client-specific failures. One browser engine, one User-Agent, one region. A WAF refusing a different request shape is invisible to it.
- Its own flakiness, honestly. Browser automation fails for reasons unrelated to the service — a timing race, a changed selector, a cookie banner in a new locale — and each of those is a false positive that erodes trust in the whole system.
The failure they BOTH miss ¶
Both run from infrastructure you chose, on a schedule you chose, against paths you chose. Neither sees a failure that affects only real users: a specific ISP's route, a gradual rollout that reached 10% of accounts, a shard that holds some users and not others. That is the class covered in why a site works for some people and not others, and the only monitoring that catches it is your own error rates from real traffic.
Which is worth saying plainly: synthetic and uptime monitoring together are still not a substitute for instrumenting the real thing. They are early warning and they are attribution — useful precisely because they run when no users are around to complain.
A sensible split ¶
| Layer | Frequency | Catches |
|---|---|---|
| Uptime check on the endpoint that matters | 1 min | Hard down, fast |
| Uptime check with a content assertion | 1-5 min | 200-but-wrong |
| Synthetic journey on the critical path | 5-15 min | Multi-step breakage |
| Real-user error rate | continuous | Everything the above cannot reach |
If you only have budget for one, make it the middle row. An uptime check with a content assertion against the endpoint whose failure hurts costs almost nothing and catches the largest share of what actually goes wrong.
The mistake worth avoiding ¶
Running many uptime checks against easy endpoints and reporting the aggregate as service health. It produces a dashboard that is green during outages, which is worse than having no dashboard — because a green dashboard is actively used as evidence that nothing is wrong.
A check is worth exactly as much as the assumption behind it: that the thing measured is the thing users depend on. Most monitoring never revisits that assumption after the day it was set up.
The maintenance cost nobody budgets for ¶
Uptime checks are close to free to keep running. Synthetic journeys are not, and the cost is not the vendor bill — it is that they break when the product changes.
A renamed button, a new cookie banner in one locale, an extra verification step: each breaks the script, each produces a failing check, and each failure looks exactly like an outage until someone reads it. A synthetic suite nobody maintains converges on being muted, and a muted check is worse than no check because it still appears on the dashboard as coverage.
Budget the maintenance or run fewer journeys. Two that are kept working beat ten that are half-broken, because the two are believed.
Where each belongs in an on-call rotation ¶
- Uptime check fails — page immediately, after debounce. Fast, unambiguous, low false-positive rate once the timeout is sane.
- Content assertion fails — page. This is the highest signal-to-noise alert most teams have: the endpoint answered and the answer was wrong, which is almost never a monitoring artefact.
- Synthetic journey fails once — do not page. Investigate on the next occurrence, or when a second signal agrees. The false-positive rate is too high to wake someone for one failure.
- Synthetic journey fails repeatedly, or error rates move — page. Two independent signals agreeing is worth more than either alone.
The general rule: page on the checks whose failures are unambiguous, and use the ambiguous ones for context once someone is already looking.