Uptime monitoring is the practice of sending scheduled requests to your websites, APIs and servers from outside your own infrastructure, checking each response against rules you set (status code, content, response time, certificate), and alerting your team when a failure is confirmed, so you learn about outages before your customers report them.
Uptime is the share of time a service is up and usable, usually a percentage of a month or a year. If you want the definition first, with the formula and what 99.9% allows in downtime, read "What is uptime?" at sutramx.com/guides/what-is-uptime. This guide is about how you monitor it.
How does uptime monitoring work?
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 monitoring vs real-user monitoring: what is the difference?
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 can an uptime check 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 should you 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.