Uptime SLAs: what 99.9% actually guarantees, and what you get if it fails
An uptime guarantee is a billing term, not an engineering commitment. The compensation is almost always a service credit you have to ask for, and it will not cover what an outage costs you.
Key takeaways
- 99.9% uptime permits about 43 minutes of downtime a month — nearly nine hours a year.
- An SLA is a refund policy, not an engineering guarantee. It defines what you get back, not what will happen.
- Compensation is almost always a service credit against future hosting, not cash, and you usually have to claim it.
- Scheduled maintenance is typically excluded from the calculation entirely.
- Shared hosting SLAs are close to meaningless in practice; the credit is worth pennies.
Almost every host advertises a 99.9% uptime guarantee. It appears on the pricing page next to the specifications, formatted like a feature, and it is routinely read as "this host is reliable".
It is more accurately read as "here is the formula we use to calculate a refund if we are not". Both readings are legitimate; only one is useful when comparing.
What the numbers permit
Uptime percentages compress badly. The difference between 99.9% and 99.99% looks like a rounding error and is a factor of ten.
| Guarantee | Per month | Per year |
|---|---|---|
| 99% | 7.2 hours | 3.65 days |
| 99.9% ("three nines") | 43 minutes | 8.8 hours |
| 99.95% | 21.6 minutes | 4.4 hours |
| 99.99% ("four nines") | 4.3 minutes | 53 minutes |
| 99.999% ("five nines") | 26 seconds | 5.3 minutes |
So a host meeting its 99.9% guarantee exactly could be down for 43 consecutive minutes every month and remain fully compliant. For a brochure site that is irrelevant. For a store on a launch day it is not.
Why it is a refund policy
Read the actual SLA text and it has a consistent structure: a definition of downtime, a set of exclusions, a compensation schedule, and a claims process. It describes what happens after an outage. It contains no commitment about how likely one is.
This is not cynicism about hosts — it is what an SLA is. No provider can promise a server will not fail. What they can do is put a price on failing, which gives them an incentive to invest in reliability. The document is the price list.
Four things in that text determine whether the guarantee means anything.
1. What counts as downtime
Usually: the server is completely unreachable, verified by the host's own monitoring, sustained for some minimum period.
What usually does not count: the site being slow, a database error while the server responds, one site down while the server is up, problems the host attributes to your code or plugins, or DNS issues. In practice a large share of real-world "my site is down" experiences fall outside the definition.
2. The exclusions
Standard exclusions include scheduled maintenance (often with limited notice required), emergency maintenance, DDoS and other attacks, third-party network failures, your own software, and force majeure.
Scheduled maintenance is the significant one. If it is excluded, a host can take your site down deliberately and still report 100% uptime. Check whether the SLA caps how much scheduled maintenance is permitted — better ones do.
3. The compensation
Almost always a service credit against future hosting, on a sliding scale. A typical structure gives 5% of the monthly fee for a small breach, rising to perhaps 50% or 100% for a severe one.
On a $5/month shared plan, a day-long outage might yield a credit of a few dollars — usable only by remaining a customer. It does not approach the cost of the outage to you, and it is not intended to. Consequential loss is explicitly excluded in essentially every hosting contract.
4. The claims process
Credits are rarely automatic. You typically have to open a ticket within a defined window — often 30 days — with times, dates and evidence.
Which means the compensation is real but conditional on you noticing the outage, documenting it, and claiming within the deadline. Most people do none of those things, which is a significant part of why the guarantees are affordable to offer.
How to actually assess reliability
Since the SLA does not tell you, use these instead.
Independent monitoring. Third-party uptime monitors track hosts continuously and publish results. Imperfect — they test a specific server, not yours — but it is measured data rather than a marketing claim.
The status page. Does the host publish one? Does it have real history, or is everything permanently green? A status page with a candid incident record, including postmortems, is a genuinely strong signal — it means someone internally is accountable for accuracy.
How they communicate during incidents. Look at their social accounts during a past outage. Prompt, specific updates indicate a functioning operations culture. Silence tells you what to expect when it happens to you.
Architecture. A single shared server has one failure domain. A platform distributing across multiple machines or a CDN has fewer ways to fail completely. This tells you more than the percentage does.
Setting your own monitoring
Whatever the SLA says, monitor your own site. Free tiers of standard uptime monitoring services check every few minutes and alert you by email.
Two reasons. You find out before your customers do. And you accumulate the independent evidence needed to actually claim a credit — without your own record, you are relying on the host's monitoring to establish that the host was down.
When it matters, and when it does not
Largely ignore the SLA for brochure sites, blogs, portfolios, and anything where an hour offline costs nothing. Choose on price, support and renewal rate. The credit on a cheap plan is worth so little that it should not influence the decision.
Take it seriously for stores, booking systems, anything with paying users, or where an outage costs money or reputation. Then look for 99.95% or better, a capped scheduled-maintenance clause, a published status page with real incidents, and independent monitoring data.
And if downtime genuinely costs you meaningful money, the answer is not a better SLA — it is architecture that survives a host failing: backups you have tested restoring, and a plan for switching. No credit compensates for a lost launch.
The comparison table records uptime guarantees where providers publish them, as a stated feature. Read them as what they are — a refund formula — and weigh the drawbacks column, which reflects documented and widely reported reliability problems, more heavily.
Further reading
- How to read a hosting price page — including whether backups are actually included.
- Choosing a hosting type — failure modes differ by category.
- Migrating hosts — the real remedy for a host you cannot rely on.