The basic mechanism
A monitoring system holds a list of endpoints and a schedule. On each tick it sends a real request to each endpoint from a machine that has nothing to do with your infrastructure, grades the response against conditions you defined, and records the result.
That external vantage point is the entire value proposition. Your own servers cannot tell you that your DNS record is wrong, that your load balancer is unreachable, or that your certificate expired — because from inside, everything looks fine.
Synthetic versus real-user monitoring
These two approaches answer different questions and most mature teams run both. Understanding what each one misses is the key to knowing when you need the other.
- Synthetic monitoringScripted checks on a fixed schedule from fixed locations. Consistent, works with zero traffic, and catches problems at 4am when nobody is using the site.
- Real-user monitoring (RUM)Instrumentation in the actual client reporting what real people experienced. Captures genuine device, network, and geographic diversity you could never script.
- What synthetic missesProblems that only appear on specific devices, browsers, or network conditions you did not think to test.
- What RUM missesA total outage. If the page will not load, there is no client left to report that it did not load. RUM goes silent exactly when you need it loudest.
This is the single most important reason to run synthetic checks. When a service is completely down, real-user monitoring shows a traffic drop that looks identical to a quiet Sunday. A synthetic check shows a failure.
What a check can verify
The depth of a check ranges from trivial to genuinely thorough, and the right level depends on what breaking would cost you.
- Reachability — does a connection open at all
- Status code — did the server return what you expect
- Content — does the response body contain what it should
- Latency — did it answer within an acceptable time
- Certificate — is TLS valid and not close to expiring
- Transaction — does a multi-step flow such as login still complete
The false positive tax
A naive monitor that alerts on every single failed request will page you constantly, because the internet drops packets for boring reasons all the time. Within a few weeks the team learns to ignore the alerts, and the monitoring is now worse than useless — it provides false confidence.
Serious monitoring systems confirm a failure from multiple independent locations before declaring an outage. One region failing is a hypothesis; several regions agreeing is an incident.
Where to start
If you have nothing today, do not try to build comprehensive coverage in one sitting. Start with the single endpoint whose failure would cost the most — usually checkout, login, or your primary API — at a one-minute interval, alerting to a channel your team actually reads.
Get that working and trusted. Then expand outward. Coverage that people believe is far more valuable than coverage that is complete.