Define "down" before you measure anything
The most basic definition — did the server respond at all — misses an entire category of real outages: a server that responds with a 500 error on every request is "up" by that definition but completely broken for every visitor. A more honest definition of available requires: the server responded, within an acceptable time limit, with a success status code, and (ideally) with expected content in the body. Each of those is a separate check that a bare "is it reachable" test doesn't perform.
Check frequency sets your resolution, not just your responsiveness
Checking every 5 minutes means any outage shorter than 5 minutes has a real chance of falling entirely between two checks and never being recorded at all — not underreported, literally invisible to the measurement. Checking every 30 seconds catches outages 10x shorter. This isn't just about noticing problems faster; a monitoring interval that's too coarse will report a higher uptime percentage than customers actually experienced, because check gaps hide the very outages you're trying to measure.
Where you check from changes what you measure
A single monitoring location measures "is the site reachable from that one network path" — which conflates two very different problems: the site actually being down, versus a routing or ISP issue specific to that one vantage point. Checking from multiple, geographically distributed locations and requiring agreement across several of them before declaring an outage (rather than trusting any single check) substantially reduces false alarms caused by a single location's local network issue.
The math that "99.9%" is hiding
Uptime percentages compress an entire time period into one number, and the same percentage can mean wildly different real experiences:
- 99.9% over a month ≈ about 43 minutes of downtime — could be one 43-minute outage, or 86 separate 30-second blips.
- 99.99% over a month ≈ about 4 minutes — a much tighter bar, and one that's meaningfully harder to hit without redundant infrastructure.
Reporting the actual outage count and longest single outage alongside the percentage gives a far more honest picture than the percentage alone — a single number can't distinguish "one bad afternoon" from "chronically flaky."
Partial degradation doesn't fit a binary up/down model at all
A site that's technically responding but takes 8 seconds to load isn't "down" by any status-code-based check, but it's failing real users just as surely as an outage would. Availability measurement that only tracks up/down, with no response-time threshold, will systematically miss this entire category of degradation — worth tracking as its own metric alongside strict availability, not folded into the same number.