“99.9% uptime guaranteed.” It appears on nearly every hosting sales page, and it sounds reassuring — until you ask what it actually means. An uptime guarantee is a contract term, defined in a document called a Service Level Agreement (SLA), and the difference between the marketing headline and the contract reality is where site owners get surprised. This guide translates uptime promises into plain numbers: what the percentages mean in minutes, how SLA credits work, and how to read the fine print like someone who has been burned before.
Uptime, Defined Without the Jargon
Uptime is the percentage of time a service is operational and reachable over a given period — usually measured monthly. Downtime is everything else: the minutes (or hours) when your site cannot be reached because of a problem on the provider’s side.
An SLA (Service Level Agreement) is the contractual promise about uptime: the provider commits to a target percentage, defines exactly what counts as “down,” and specifies what happens — usually service credits, not cash refunds — if it misses the target. The SLA is the only part that matters legally. The marketing page is not the contract, no matter how prominently the percentage is displayed.
The Math of Nines: What Each Percentage Means
Hosting people talk about “nines” — the string of 9s in the uptime figure. Each additional nine cuts allowed downtime by roughly a factor of ten. Here is what the common guarantees translate to per month (based on a 30-day month of 43,200 minutes):
| Uptime guarantee | “Nines” | Allowed downtime per month | Allowed downtime per year |
|---|---|---|---|
| 99% | Two nines | ~7 hours 12 minutes | ~3.65 days |
| 99.9% | Three nines | ~43 minutes | ~8.77 hours |
| 99.95% | Three and a half nines | ~21.6 minutes | ~4.38 hours |
| 99.99% | Four nines | ~4.3 minutes | ~52.6 minutes |
| 99.999% | Five nines | ~26 seconds | ~5.26 minutes |
Read that table slowly, because it reframes every sales page you will ever see. “99.9% uptime” — the industry-standard promise — permits 43 minutes of downtime every single month, or nearly nine hours a year, without the provider breaking its word. “99%” permits more than seven hours a month. The percentages sound near-perfect; the minutes tell the real story.
Also note what the table assumes: a 30-day month. Providers define the measurement window in the SLA, and some exclude scheduled maintenance from the calculation entirely — which brings us to the fine print.
What Counts as “Down”? (The Fine Print)
An SLA never promises “your website works.” It promises something narrower, defined in precise terms. Typical exclusions and definitions include:
- Scheduled maintenance windows are usually excluded. If the provider announces downtime in advance per the SLA’s notice rules, those minutes do not count against the guarantee.
- Problems outside the provider’s control — upstream internet outages, DNS issues at your registrar, DDoS attacks beyond a certain scale, or your own misconfiguration — are excluded. The SLA covers the provider’s infrastructure, not the whole internet.
- Partial degradation may not count. If your site is reachable but slow, most SLAs do not consider that “down.” The definition is usually binary: reachable or not, measured by the provider’s own monitoring.
- Measurement method matters. The provider measures with its own systems, from its own vantage points, at its own sampling intervals. Brief blips that its monitors miss may not register at all.
- Your stack is your problem. If the provider’s network is up but your application crashed because of a bad deploy, that is not SLA downtime. The guarantee covers the infrastructure layer you bought, nothing above it.
None of this is dishonest — it is just narrower than the headline implies. The fix is to read the SLA itself, which is usually a short document, and note exactly what is promised, what is excluded, and how downtime is measured.
How SLA Credits Work (and Why They Disappoint)
When a provider misses its uptime target, the remedy is almost always service credits — a percentage of your bill knocked off a future invoice. Key things to know:
- You usually have to claim them. Credits are rarely automatic. The SLA specifies a claim window (often 30 days after the incident) and requires you to file a ticket with evidence. Miss the window, get nothing.
- The credit is a fraction of a fraction. A typical schedule: 10% credit for missing the target modestly, 25–30% for a serious breach. On a modest hosting bill, that is pocket change — it does not compensate for lost sales during an outage.
- Credits are not refunds. They reduce future bills; they do not return money already paid, and they certainly do not cover your business losses.
- Caps apply. Most SLAs cap total credits at 100% of one month’s fees for the affected service — and “affected service” is defined narrowly.
The takeaway: SLA credits are a accountability mechanism, not insurance. They give the provider a financial reason to stay up, but they will never make you whole after a bad outage. Real protection comes from your own architecture — backups, redundancy, and a host whose actual track record you trust — which is why uptime belongs in the same conversation as hosting security basics.
Marketing Uptime vs Real-World Reliability
Here is an uncomfortable truth: the SLA percentage tells you almost nothing about how reliable a provider actually is. Two providers can both promise 99.9% while one has three brief blips a year and the other has one eight-hour outage. Same “nines,” wildly different experiences.
What actually predicts reliability:
- Track record. Public status pages with honest incident histories are gold. A provider that publishes detailed post-mortems is usually more reliable than one with a spotless-looking page and no history.
- Architecture. Redundancy across availability zones, automatic failover, and geographic distribution are what keep sites up during real failures. Ask how the provider handles a zone failure, not just what percentage it promises.
- Your own setup. A single server in one zone has a single point of failure no matter what the SLA says. Multi-zone deployment, tested backups, and a CDN in front do more for your real uptime than any contractual percentage.
Be especially skeptical of uptime figures quoted without an SLA behind them (“we typically deliver 99.99% uptime!”). Without a contract defining measurement and remedy, that is marketing copy, not a promise.
Monitor Your Own Uptime — Don’t Take Their Word for It
The provider’s SLA is measured by the provider’s monitors. You should run your own. Independent uptime monitoring is cheap (often free for basic checks) and it serves two purposes: it tells you about outages before your visitors do, and it gives you your own evidence if you ever need to file an SLA credit claim.
Set up checks that match what visitors experience: an HTTP check against your homepage and one or two key pages, run every few minutes from multiple geographic locations. A check from a single location can cry wolf over a local network blip; checks from several continents agreeing that you are down is a real signal. Configure alerts to reach you immediately — email is too slow for a production outage; use push notifications or SMS.
Keep a simple incident log: date, duration, apparent cause, and what fixed it. Over a year, this log becomes the most honest reliability record you own — more useful than any SLA percentage when you are deciding whether to renew, renegotiate, or migrate. It also disciplines the post-incident review: every outage should produce at least one preventive action, whether that is a configuration fix, a monitoring improvement, or an architecture change.
Quick Glossary
- Uptime
- Percentage of time a service is operational over a measurement period.
- Downtime
- Time the service is unavailable, as defined (and limited) by the SLA.
- SLA (Service Level Agreement)
- The contract defining the uptime target, measurement method, exclusions, and remedies.
- Service credit
- Bill reduction granted when the provider misses its SLA target; claimed by the customer, capped, and never cash.
- Scheduled maintenance
- Announced downtime windows, usually excluded from SLA calculations.
- MTBF / MTTR
- Mean time between failures / mean time to repair — engineering metrics describing how often things break and how fast they are fixed. More informative than a bare percentage, rarely published.
- Status page
- The provider’s public incident log. Bookmark it before you need it.
Before You Trust an Uptime Promise: A Checklist
- Find the actual SLA document (not the marketing page) and read the uptime clause.
- Convert the percentage to minutes per month using the table above. Is that acceptable for your site?
- Note the exclusions: scheduled maintenance, force majeure, your own errors.
- Check the credit schedule and the claim process — including the deadline.
- Look at the provider’s public status history for the last 12 months.
- Ask what happens architecturally during a zone failure — the answer matters more than the percentage.
- Set up your own external monitoring. Never rely solely on the provider to tell you when you are down.
The Bottom Line
Uptime guarantees are useful — but only when translated. “99.9%” means 43 minutes of permitted downtime a month. SLA credits are discounts, not compensation, and you have to claim them within the deadline. The contract is narrower than the headline, the provider’s track record matters more than its promise, and your own architecture (redundancy, backups, monitoring) is the real determinant of whether your visitors see your site. Read the SLA once, set up independent monitoring, keep your own incident log, and you will never be surprised by an uptime promise again. Pair this understanding with protection against the other kind of downtime — malicious traffic — covered in our guide to DDoS protection basics.
