99.9% uptime is eight hours and forty-five minutes a year
The arithmetic is one line. Allowed downtime is the length of the period multiplied by one minus the target. Everything else about uptime percentages is definitions, and the definitions are where the money is.
The table
Computed on a 365-day year, a 30-day month, and a 7-day week.
| Target | Per year | Per month | Per week | Per day |
|---|---|---|---|---|
| 99% | 3 d 15 h 36 m | 7 h 12 m | 1 h 40 m | 14 m 24 s |
| 99.5% | 1 d 19 h 48 m | 3 h 36 m | 50 m 24 s | 7 m 12 s |
| 99.9% | 8 h 45 m 36 s | 43 m 12 s | 10 m 5 s | 1 m 26 s |
| 99.95% | 4 h 22 m 48 s | 21 m 36 s | 5 m 2 s | 43 s |
| 99.99% | 52 m 34 s | 4 m 19 s | 1 m 1 s | 9 s |
| 99.999% | 5 m 15 s | 26 s | 6 s | 1 s |
Two rows are worth reading against each other. Between 99.9% and 99.99% the yearly budget drops from most of a working day to under an hour. That is not one more decimal place of effort, it is a different operational model: automatic failover, no manual step in a recovery, and a deployment process that cannot take the site down. Almost nothing built for a small business clears it, and quoting it is a promise you will break.
The bottom row exists in marketing copy and essentially nowhere else. Twenty-six seconds a month is less than the time it takes a human to read an alert.
The three definitions that decide the number
Give the same month of the same website to three people and you can get three different uptime figures, all honest.
What counts as down. A server answering 500 to every request is obviously down. A page that loads in eighteen seconds is not, by most definitions, and is worse for the client than a clean outage because visitors sit and wait. A page that returns 200 with an empty product listing is up by every status-based measure ever built, and is the exact failure that costs a retailer a day of sales. If the definition is "the check passed", the percentage measures the check, not the site.
Where it is measured from. One probe in one data centre gives one number. Five probes in five regions give a different one, and it will be lower, because you are now seeing regional routing failures that the single probe never encountered. Neither is wrong; they answer different questions. What is wrong is comparing your figure to a provider's figure when the two were gathered differently, which is most comparisons.
How often it is measured. This one is arithmetic rather than opinion, and it is the one people miss. A check every five minutes cannot detect an outage shorter than five minutes. It also cannot tell you when an outage started, only that it had started by the time of the failing check, so every recorded incident is credited with up to one interval of extra downtime it may not have had, or has an interval of real downtime invisible in front of it. On a 99.9% budget of forty-three minutes a month, a five-minute sampling interval is a measurement error of the same order as the entire budget.
The practical consequence: if you intend to report a percentage to a client, the check interval has to be small relative to the downtime you are promising. Promising 99.9% and sampling every five minutes is reporting a number your instrument cannot resolve.
What the exclusions do to it
Every published uptime commitment carves out a list, and the list is longer than the commitment. Planned maintenance announced in advance. Anything caused by the customer's own code or configuration. Anything upstream: transit providers, DNS, certificate authorities. Force majeure. Beta features.
Read that list as the real specification. A provider can be entirely truthful about 99.99% while the client's site was unreachable for two hours, because the outage was a planned window, or because it happened at the CDN, or because the failing component was categorised as a dependency rather than a service.
None of that is fraudulent, and it is why the number a hosting provider publishes and the number your own probe records are not the same measurement and should not be compared. Yours includes everything the visitor experienced. Theirs includes what they agreed to be liable for.
What a service credit is worth
Worth doing once with real figures, because it changes how you write your own contracts.
A typical credit is a percentage of the monthly fee for the affected service, capped at the fee itself, and claimable only if the customer files within a window. On a hosting plan costing a few tens of currency units a month, a full month's credit is a rounding error against a day of lost trading for the client. The credit is not compensation, it is an admission mechanism.
Which means the number in an SLA is a signal about the provider's confidence, not an insurance policy. Choose on architecture and on incident communication, and treat the percentage as a description of what they think they can do.
The number to give a client instead
An agency reselling maintenance is usually asked for an uptime guarantee, and usually should not give one, because you do not control the hosting, the DNS, the CDN, the payment processor or the client's own plugin choices. Guaranteeing an outcome you cannot cause is how a good relationship acquires a bad clause.
What you can commit to, and what actually distinguishes you, is the part you do control:
Detection. "Any outage is detected within N minutes, at any hour." That is a property of your monitoring and you can prove it.
Notification. "You hear from us before you hear from a customer." This is the promise the client actually wants, and the one they will remember, because the injury in an outage is discovering it from an angry email.
Response. "Someone is working on it within N minutes during hours, N hours outside them." Say the outside-hours number honestly. A one-person business that promises twenty-four hour response is promising to be woken up, and the alternative is described in what to send a client, and when.
Then report the three numbers monthly, including the months where nothing happened. A report that says "no incidents, four checks per minute, all green" is the cheapest renewal argument there is, and it is only credible if the check behind it asserts more than a status code: the layers a percentage is silently defined over.
