Why monitor from outside your own network?
External monitoring is the whole point. If you check your site only from inside your own network or from the server itself, you're testing the parts least likely to be the problem and missing the ones most likely to affect customers — DNS resolution, upstream connectivity, expired certificates, and the path between the wider internet and your service. A server can be perfectly healthy while customers can't reach it, and internal checks will happily report 'all good.'
Good monitoring runs from multiple locations on the public internet and asks the same question a customer's browser asks: can I resolve this name, connect over HTTPS with a valid certificate, and get the expected page back? Checking from several geographic locations also distinguishes a real outage (down everywhere) from a localized network problem (down from one region only), which changes how you respond.
What should you actually monitor (it's more than a ping)?
Start with reachability but don't stop there. A basic check confirms the server responds; a good check confirms the right thing came back. Layer your monitoring so each layer catches failures the one below it misses:
| Layer | Question it answers | Failure it catches |
|---|---|---|
| Reachability (ping/TCP) | Is the host reachable at the network level? | Host or network path down |
| HTTP/HTTPS status | Does the web server return a success status? | Web server returning errors |
| TLS certificate | Is the certificate valid and not near expiry? | A scheduled, preventable certificate-expiry outage |
| Page content | Does the returned page contain expected content? | Error pages or a hijacked placeholder |
| Transaction (synthetic) | Does a real user flow like checkout or login work? | Broken checkout or login while the homepage still loads |
| Server resources | Disk, memory, CPU, and key service health | Trouble before it becomes an outage — a filling disk or memory exhaustion |
For anything transactional, monitor the transaction, not just the homepage. A storefront can serve its homepage perfectly while checkout is broken; a portal can load while login fails. Certificate expiry deserves its own explicit monitor, because it's a scheduled, preventable outage that a plain uptime check often won't warn you about until it actually happens. On the server side, reachability tells you something already broke; resource monitoring gives you warning before it does — a disk filling up or memory exhaustion is far cheaper to catch as a trend than as an outage.
How often should you check, and what counts as down?
Check frequently enough that your detection time is shorter than your tolerance for downtime. The tradeoff is mostly cost and check volume, not technical difficulty, so for customer-facing services shorter intervals are worth it.
| Check interval | Unnoticed downtime before first alert |
|---|---|
| One minute | About a minute |
| Five minutes | Up to five minutes |
Decide deliberately what counts as 'down' to avoid false alarms. A single failed check can be a transient network blip rather than a real outage. A common, sensible pattern is to confirm a failure from more than one location or across two consecutive checks before declaring an incident and paging someone. This confirmation step is what separates monitoring that people trust from monitoring that everyone learns to ignore because it alerts on noise.
How do you build alerting that people actually act on?
An alert is only useful if it reaches the right person, fast, through a channel they'll notice. A monitoring email in an inbox nobody watches at night is not an alerting strategy. Route genuinely urgent alerts to something immediate — a phone notification, a text, or a paging tool — and define who is responsible for responding at any given hour. The goal is that a real outage wakes the right person, and a non-urgent warning does not.
Close the loop with escalation: if the first responder doesn't acknowledge within a set time, the alert should escalate to someone else. Outages don't wait for one person to be awake and available, and an unacknowledged critical alert should keep climbing until a human owns it.
How do you turn monitoring data into fewer outages?
Monitoring earns its keep beyond the moment of an outage. The history it collects — how often things fail, how long recovery takes, which components are flaky, whether response times are creeping up — is what lets you fix root causes instead of repeatedly reacting. A service that dips briefly every night, or a page that's slowly getting slower, is a problem you can address before it becomes an outage, but only if you're recording and reviewing the data.
Uptime figures are also how you hold infrastructure to a standard and report reliability honestly to stakeholders and customers. Rather than 'it feels reliable,' you have numbers. For businesses running anything critical, monitoring is part of the infrastructure itself, not an afterthought bolted on later.