"99.9% uptime" sounds bulletproof. It is not. Three nines of availability means your site can be down for 8 hours and 45 minutes a year and the SLA is still met. Four nines, 99.99%, gives you 52 minutes a year. Five nines, the famous gold standard, allows just over 5 minutes annually. Most teams promise numbers they couldn't measure if you asked them to, and would never hit if they did.
This post is the cheat sheet: what each "nines" tier actually translates to in real downtime, where the terminology comes from, what's realistic to promise, and how to measure the number you commit to.
The Math
Uptime percentages are deceptive because they're nonlinear. The difference between 99% and 99.9% sounds small, a tenth of a percent, but it's the difference between 3.65 days of downtime a year and 8.76 hours. Every additional nine reduces allowed downtime by 90%.
The formula is simple: allowed downtime = total time × (1 − uptime percentage). A year is 525,600 minutes. A 99.9% SLA permits 525.6 minutes of downtime per year. Most teams calculate this once, write it into a contract, and never look at it again. That's a mistake, your error budget is the single most useful number in your monitoring practice.
The Uptime Cheat Sheet
| Uptime | Per year | Per month (30 days) | Per week |
|---|---|---|---|
| 99% (two nines) | 3.65 days | 7.2 hours | 1.68 hours |
| 99.5% | 1.83 days | 3.6 hours | 50.4 minutes |
| 99.9% (three nines) | 8.77 hours | 43.8 minutes | 10.1 minutes |
| 99.95% | 4.38 hours | 21.9 minutes | 5.04 minutes |
| 99.99% (four nines) | 52.6 minutes | 4.38 minutes | 1.01 minutes |
| 99.999% (five nines) | 5.26 minutes | 26.3 seconds | 6.05 seconds |
A few things jump out of that table. Anything below 99.9% is barely worth promising, a 99% SLA is essentially "we'll be up most of the time". Five nines is a ridiculous commitment for any single-region deployment; you cannot afford a single full minute of downtime per month. Most SaaS providers operate at three to four nines and price their SLAs accordingly.
Where the "Nines" Terminology Comes From
The shorthand is older than the modern web. Telephone carriers in the 1970s used it to describe switch availability, and it migrated into computing in the 1980s as mainframe vendors started writing availability into hardware contracts. The convention stuck because it's compact: "five nines" is faster to say than "99.999 percent" and immediately conveys the order of magnitude.
In conversation, you'll hear:
- Two nines: 99%, the floor of any serious commitment.
- Three nines: 99.9%, the typical promise for shared hosting and budget SaaS.
- Four nines: 99.99%, the working-day standard for serious B2B services.
- Five nines: 99.999%, the aspirational target of legacy telco and high-availability database vendors.
Anything above five nines (six nines is 32 seconds a year) is a rounding error and almost no real-world service can claim it honestly.
What's Realistic at Each Tier
The number you can deliver depends almost entirely on your architecture, not your effort:
- Shared hosting: realistically two to three nines. You're sharing infrastructure with sites you can't see, on hardware you don't control. Anything beyond 99.9% is a coincidence, not an achievement.
- VPS or single-region cloud: three nines is achievable with good monitoring and a same-region failover. Four nines is hard without multi-AZ.
- Multi-AZ managed platform: four nines is the right target. Single-AZ failures don't take you down; only regional or platform-wide events do.
- Multi-region active-active: four to five nines, with most of the remaining downtime coming from DNS, third-party dependencies, and your own deployments. See the global uptime monitoring guide for why multi-region matters.
The honest version of every promise above is "minus any time we shoot ourselves in the foot". Deployments, expired certs, DNS edits, and database migrations cause more outages than infrastructure failures do. Your SLA target should account for the downtime you cause yourself, not just the downtime imposed on you.
How SLA Windows Are Measured
Two SLAs both promising "99.9% uptime" can mean wildly different things depending on the measurement window:
- Rolling 30-day window: at any moment, the last 30 days must show at least 99.9% uptime. The strictest version; one bad week haunts you for a month.
- Calendar month: uptime is calculated from the 1st to the last day of each month. Easier to game with end-of-month deploys.
- Calendar year: annual aggregation. Almost meaningless for client communication; nobody waits 11 months to find out their site was down 8 hours.
You also need an explicit position on scheduled maintenance. Most SLAs exclude pre-announced maintenance windows, say, "the second Tuesday of each month, 2–4am UTC". If yours doesn't say, clients will assume it doesn't. Write it down or stop promising it.
For a full template you can adapt for client contracts, see how to create an uptime SLA for client websites.
How to Actually Measure Your Uptime
Your hosting provider's uptime number lies. Not because they're dishonest, but because they're measuring something different than your customers experience. A server can be 100% reachable from inside the data center while DNS, CDN, or BGP issues make it completely unreachable from the public internet.
The only number that counts is what an external observer sees:
- External, not internal, checks must run from outside your own network.
- Multi-region: a single check point can only tell you about its own connectivity. Real measurement requires consensus from several geographic locations.
- Frequent: your check interval bounds the precision of your measurement. A 5-minute interval can't measure better than 99.5% reliably.
This is what external monitoring tools exist to do. Internal metrics are useful for diagnosing why an outage happened; they cannot tell you whether one is currently happening to your customers.
What to Promise Clients
The temptation is to promise 99.9% because everyone does. The honest version of this conversation looks more like:
- Tell clients what you can actually deliver based on their hosting setup, not the industry-standard number you read in a blog post.
- Promise the tier below what you measure. If you observe 99.95% over the past quarter, promise 99.9% in the contract. Buffer for the bad month.
- Tie the SLA to a specific measurement method (external, multi-region, X-minute checks) and a specific reporting cadence (monthly uptime reports, ideally automated).
- Cap your liability. Most service-credit clauses refund a percentage of the monthly fee, not the cost of the client's downtime, see the true cost of website downtime for why that distinction matters.
A clear, slightly-conservative SLA backed by external monitoring is far more useful to a client than a five-nines fantasy you can't measure.
Putting It in Practice
Sentinel measures uptime from multiple regions, requires consensus before counting a check as failed, and generates automated client-facing uptime reports you can hand straight into a monthly invoice. See pricing, the free tier covers 10 monitors with no credit card.