What an uptime percentage actually promises
An uptime percentage is a ratio over a stated window, not a promise about any particular hour. A year at 99.9% leaves 8h 45m 36s of downtime. A single day at that same 99.9% leaves 1m 26s. That gap is why a service level is meaningless until you know the window it is measured over. A provider quoting monthly 99.9% can be dark for 43 minutes in March, recover, and still owe you nothing. Quoted annually, those same 43 minutes are a rounding error, and one bad afternoon in November can be absorbed on top of them.
Why the measurement interval matters
The table above is a budget. What you can actually observe is a different question, and it is bounded by how often you look. A monitor running every five minutes samples your service 288 times a day. A 30-second outage that lands between two checks is not under-reported; it is never seen at all. Tighten the interval to 60 seconds and you take 1,440 samples, and the shortest outage you can reliably catch shrinks with it. This is the practical ceiling on any uptime figure computed from check results: you are reporting the availability of your samples, not of your service.
The arithmetic gets uncomfortable at the top end. One missed check on a five-minute interval is already five minutes of unexplained time, which is comfortably more than the entire annual budget at 99.999% (5m 15s). If you intend to claim four or five nines, the interval has to be able to support the claim. Vantage point matters for the same reason: a single probe reporting a timeout may be describing the network path rather than the service, so a second location confirming the failure is what separates a real outage from a bad route.
What each nine costs
Every nine is a factor of ten less downtime and a large step up in engineering. 99% is one careless deploy a month. 99.9% is reachable with a single well-run server, careful releases, and somebody who answers the phone. 99.99%, at 52m 34s a year, means redundancy in every layer and automated failover, because 52 minutes is roughly one incident where a person gets paged, logs in, and thinks. 99.999%, at 5m 15s a year, takes humans out of the recovery path entirely; the budget is spent by one unlucky failover. Most teams are better served by choosing a number they can genuinely hold, measuring it honestly at a tight interval, and publishing it on a status page than by promising a nine they will quietly stop reporting.
Questions
How is allowed downtime calculated?
Subtract the uptime percentage from 100 to get the unavailable fraction, then multiply it by the length of the period. 99.9% over a 30-day month is 0.001 times 2,592,000 seconds, which is 2,592 seconds, or 43m 12s.
Should an SLA be measured monthly or annually?
Monthly windows are stricter in practice: a single bad month cannot be absorbed by eleven good ones, and credits are calculated on a period the customer can remember. Annual windows flatter the provider. Always read which one an SLA uses before comparing two numbers.
Does my check interval change my uptime number?
Yes. A monitor can only report on the moments it sampled. On a 5-minute interval you take 288 samples a day, so a 30-second outage between two checks is never observed at all. Tighter intervals detect shorter outages and produce a more honest figure.
Does planned maintenance count against the budget?
That depends entirely on the contract, and it is the most common place two SLAs stop being comparable. Many providers exclude announced maintenance windows. Your users do not, so it is worth tracking both numbers: contractual uptime and observed uptime.
Measure it instead of estimating it
Undownable watches from the outside and keeps the uptime record for you. The free plan covers 10 monitors on 5-minute checks with all alert channels, and every account starts with a 14-day Pro trial (60-second checks, no card).
Start free