What Web Hosting Uptime Claims Actually Tell You
Learn what a 99.9 percent uptime claim really permits in monthly downtime, how providers measure availability, and what hosting SLAs exclude.
Facts that can change should include a source and check date. Benchmark claims should state the plan, region, method, and test period.
Read an uptime percentage together with its measurement period, exclusions and remedy. A network availability target may not measure whether your website’s pages or checkout are working.
The arithmetic behind the nines#
An uptime percentage measures availability over a fixed period, usually a month or a year. What makes these figures feel abstract is that the differences between them are much larger than they appear, because each additional nine divides the permitted downtime by ten.
| Uptime claim | Downtime allowed per month | Downtime allowed per year |
|---|---|---|
| 99 percent | About 7.3 hours | About 3.65 days |
| 99.9 percent | About 43.8 minutes | About 8.76 hours |
| 99.99 percent | About 4.38 minutes | About 52.6 minutes |
Read the monthly column again with your own site in mind. A 99.9 percent guarantee, which sounds exemplary, still permits roughly 44 minutes of unavailability in a single month. Google's Site Reliability Engineering book includes this availability table precisely because the raw percentages hide the operational reality behind them. The question is not whether a provider promises a high number, but whether that number is compatible with the amount of interruption your visitors will tolerate.
What is actually being measured#
The scope of an uptime claim matters as much as its value. Many providers measure network or physical server availability, which in practice means whether the machine responds to a ping, rather than whether your application is working. A server can answer a ping and still be serving error pages. If your site returns a 500-series error because of a crashed process or a faulty deployment, the provider may still count that interval as up, because from their side the server was reachable.
Application-layer monitoring, which checks for a successful HTTP response from an actual page, is the measurement that corresponds to what your visitors experience. When you compare two claims, the first question to ask is which of these two things each provider is measuring. A slightly lower number measured at the application layer is generally more meaningful than a higher number measured at the network layer.
What service level agreements exclude#
The guarantee itself usually arrives with a list of exclusions, and that list does a lot of quiet work. Standard agreements routinely exclude scheduled maintenance windows, outages caused by third-party networks outside the provider's control, and distributed denial-of-service events. Some exclusions are reasonable, since no provider governs the whole route between your visitor and their data centre. But the cumulative effect is that the headline percentage describes a narrower slice of reality than it appears to. A month containing planned maintenance and a traffic flood can involve substantial real downtime while remaining fully compliant with the agreement.
None of this makes exclusions illegitimate. Maintenance has to happen somewhere, and attacks are not chosen by the victim. The problem is asymmetry of information: the provider knows exactly which minutes count, and you do not, unless you ask.
What happens when the guarantee is missed#
It is worth being clear about what a service level agreement is: a contract clause that specifies a remedy, not a promise of uninterrupted service. When a provider misses its target, the standard remedy is a billing credit, meaning a partial refund of that period's fee, usually offered on request rather than automatically. Reading the AWS compute service level agreement is instructive here, because it sets out this credit mechanism in unusually explicit terms, and many smaller providers follow the same structure with less detail.
Two consequences follow. First, compensation is tied to your hosting fee, which means it is almost never proportional to the revenue a busy site loses during an outage. Second, you generally have to notice the downtime and claim the credit yourself, which requires records of your own.
How to read an uptime claim before you buy#
Four questions turn a marketing number into information:
- What layer is measured, network reachability or application responses?
- Over what window is availability calculated, monthly or annually?
- Which events are excluded from the calculation?
- If the target is missed, what is the remedy, how is it claimed, and who is responsible for noticing?
It is also worth remembering that an uptime figure is an advertising claim like any other. Guidance from the United States Federal Trade Commission on truth in advertising is blunt on this point: claims should be truthful and substantiated before they are made. A provider that cannot explain how its uptime is measured, or that publishes a figure with no methodology behind it, is telling you something useful, just not about uptime.
Finally, measure it yourself. Independent third-party monitoring from a separate location gives you a record that belongs to you rather than to your provider, and it settles disputes quickly. The most useful uptime number is the one you collected, at the layer your visitors actually use.
Sources
- Google Site Reliability Engineering (SRE) Book: Availability Table & Calculations Checked 2026-08-28
- AWS Compute Service Level Agreement (Standard SLA Structure & Credit Mechanisms) Checked 2026-08-28
- FTC Guidance: Advertising FAQs & Truth in Advertising Principles Checked 2026-08-28