99.9% uptime, often called "three nines," means a service can be unavailable for 0.1% of a given period and still meet its target. That works out to about 43 minutes per 30-day month, roughly 10 minutes per week, and about 8 hours 46 minutes per year. The number sounds close to perfect. Whether it is good enough depends on when the downtime lands, how it is measured and what you are promised if it is missed.
TL;DR
- 99.9% uptime allows about 43.2 minutes of downtime in a 30-day month and about 8.76 hours in a year, per Google's SRE availability table.
- Each extra nine cuts the allowed downtime by a factor of ten: 99.99% allows roughly 4 minutes a month.
- The percentage is a target and a contract term, not a guarantee. Scheduled maintenance is often excluded, and the remedy for a miss is usually a service credit.
- Time-based uptime can hide partial failures. Request-based availability often describes user experience better.
- "Uptime" in Windows Task Manager is a different thing entirely: it counts time since the last restart.
Table of Contents
- What 99.9% uptime actually means
- The downtime math, by period
- Nines of availability, compared
- What the SLA does and does not promise
- Why a percentage can mislead
- How much availability do you need?
- Where our view comes from
- Measure your own uptime
- Don't confuse it with Task Manager uptime
- FAQ
- Sources
What 99.9% uptime actually means
Uptime is the share of a time window during which a service was working. Metabase defines it as the percentage of time a service was up over a window, the number that ends up in SLAs and status pages. Its framing is the useful one: 99.9% is a downtime budget you get to spend.
The formula is simple. NASA's reliability documentation gives availability as uptime divided by the sum of uptime and downtime. Say a service was down for 30 minutes in a 30-day month (43,200 minutes):
- Uptime is 43,200 minus 30, which is 43,170 minutes.
- Divide 43,170 by 43,200.
- The result is 0.99931, or 99.93%.
That month passes a 99.9% target with about 13 minutes to spare. A 50-minute outage in the same month gives 99.88% and misses it.
If you want to track availability alongside other site health indicators, this guide on measuring website success with KPIs shows how a metric like this fits a wider picture.
The downtime math, by period
The figures depend on the period you measure. Most providers measure monthly, some annually, and the difference matters. Here is the arithmetic for 99.9% using a 30-day month and a 365-day year, which matches the Google SRE table (it lists 43.2 minutes a month, 8.76 hours a year and 10.1 minutes a week).
| Period | Allowed downtime at 99.9% |
|---|---|
| Per day | about 1 minute 26 seconds |
| Per week | about 10 minutes |
| Per 30-day month | about 43 minutes |
| Per quarter | about 2.16 hours |
| Per year | about 8.76 hours |
Sources vary slightly. Some quote 43.8 minutes a month because they average a month as one twelfth of a year (30.4 days). Neither is wrong. They just use different month lengths. Check which one your provider uses.
Nines of availability, compared
"Nines" is shorthand for counting the nines in the percentage. AWS's Well-Architected guidance treats availability as both a way to measure resiliency and a target. Each added nine divides the downtime budget by ten.
| Availability | Nines | Downtime per month (30 days) | Downtime per year |
|---|---|---|---|
| 99% | Two | 7.2 hours | 3.65 days |
| 99.5% | Two and a half | 3.6 hours | 1.83 days |
| 99.9% | Three | 43.2 minutes | 8.76 hours |
| 99.99% | Four | 4.3 minutes | 52.6 minutes |
| 99.999% | Five | 26 seconds | 5.3 minutes |
The month and year values for 99%, 99.5% and 99.9% appear in the Google SRE table. The four and five nines rows follow from the same formula.
A practical way to feel the gap: at three nines, a single bad deploy that takes your site down for an hour breaks the monthly budget. At four nines, a five-minute blip does.
What the SLA does and does not promise
A 99.9% figure in a contract is not a technical promise that nothing will break. IBM's documentation on the 9s points out that specifying availability is more involved than quoting a single number like 99.999%. In practice, an SLA's percentage is a framework for remedies when the provider falls short.
Check these points before you rely on a number:
- Measurement window. Monthly is stricter than annual, because one bad month cannot be averaged out against eleven good ones.
- Exclusions. Scheduled maintenance is commonly carved out of the calculation. Ask how much notice is required and how often it happens.
- What counts as down. Some definitions only count a complete outage. A site returning errors to a third of its visitors may still count as "up."
- The remedy. Usually a credit against your bill, not compensation for lost revenue.
- Who measures. A provider's own dashboard and your independent checks can disagree.
That last point is why many teams run their own external checks. If you want to see what an outside probe reports about your site, our website uptime monitor is built for that.
Why a percentage can mislead
Time-based uptime misses partial failures
Google's SRE material argues that a simple time-based percentage is often not enough for modern services. A service can be "up" by a ping check while some share of real requests fail. The alternative is request-based availability: successful requests divided by total requests. If your checkout API fails on 2% of calls all day, a time-based monitor may report 100%, while users experience something much worse.
When the downtime happens matters
Two services with the same 99.9% can feel very different. Eight hours of downtime spread across the year as short blips is annoying. The same eight hours in one outage during a product launch or Black Friday is a business event. The percentage says nothing about timing.
Adding components does not add nines
Availability is a property of the whole system. AWS's reliability guidance notes that it depends on the cumulative reliability of every component. If your app needs a web server, a database and a third-party API in series, each at 99.9%, the combined availability is about 99.7% (0.999 cubed is 0.997). Redundancy raises the figure only where you actually remove single points of failure.
How much availability do you need?
More nines cost more. Infrastructure guidance such as Lane County's service availability page notes that uptime percentages depend on availability design, standards, service management and resources. Going from three nines to four generally means eliminating single points of failure and paying for redundancy, not just watching more closely.
A rough way to decide:
- Estimate the cost of an hour of downtime. Lost sales, support load, contractual penalties.
- Compare it to the cost of the next nine. Extra regions, failover databases, on-call staffing.
- Match the target to the service. A marketing site, an internal dashboard and a payment API deserve different targets.
- Set an error budget. If 99.9% gives you 43 minutes a month, decide what you will spend it on: deploys, migrations, risk.
For many small sites and early SaaS products, three nines is a sensible and achievable target. Chasing five nines before you have monitoring, alerting and a rollback process is usually a poor use of money.
Where our view comes from
We build uptime and SSL monitoring tools, so we spend a lot of time on the gap between what a number says and what a team can act on.
Our view is simple. The percentage is a summary, and the useful work happens before it. You need an independent check that sees your site the way a visitor does. You need an alert that reaches a person fast, and a record of when each outage started and ended so you can do the math above with real timestamps instead of guesses. Most sites we see discussed lose their budget to the boring causes: an expired certificate, a bad deploy, an upstream error. A 504 or 503 response is often the first visible sign, which is why we keep plain-language references on 503 Service Unavailable and 504 Gateway Timeout.
Our advice: pick a target you can afford, measure it from outside your own infrastructure, and treat the SLA as a refund mechanism, not a safety net. If you are setting up alerts, our downtime alerts checklist covers what to configure. Expired certificates are a common self-inflicted outage, so our guide to SSL certificate monitoring is worth a look as well.
— Andreas
Measure your own uptime
To check whether your site actually meets three nines, you need data from outside your servers. Pingfloat offers a free suite of web tools, including a Website Uptime Monitor and an SSL Checker. Core tools work without installing anything or creating an account. For a walkthrough, see 15 minutes to website uptime monitoring. You can also browse the other utilities on the Pingfloat homepage.
Don't confuse it with Task Manager uptime
People searching for "uptime" sometimes land on a different question. In Windows Task Manager, the Uptime figure on the Performance tab is not service availability. It shows how long the operating system has been running since the last full restart. The Super User explanation says it counts from your last restart, in days, hours, minutes and seconds.
There is a catch. With Fast Startup enabled, a normal shutdown saves the system state to disk like a hybrid hibernation, so the counter keeps going. Only a full Restart resets it. A PC showing 20 days of uptime may have been "shut down" every night. If you suspect Fast Startup, Microsoft's Q&A thread on turning off Fast Startup discusses the setting and its effect on boot time.
FAQ
How much downtime is 99.9% uptime per month?
About 43 minutes in a 30-day month, or 43.2 minutes exactly. Some sources quote 43.8 minutes because they use an average month of about 30.4 days. Your provider's contract should state which month length it uses.
How do you calculate availability percentage?
Divide uptime by the total of uptime and downtime, then multiply by 100. If a service was down for 20 minutes in a 30-day month, that is 43,180 divided by 43,200, or about 99.95%. This is the same formula described in NASA's availability document.
How many nines of reliability are enough?
It depends on what an hour of downtime costs you and what the next nine costs to build. Three nines suits many websites and early-stage products. Four or more usually requires redundant architecture and is worth it mainly when outages are expensive.
Is 99.9% uptime a guarantee?
No. It is a target written into a service agreement, often with maintenance exclusions. If the provider misses it, the usual result is a service credit, not a promise that outages cannot happen.
What is the difference between 99.9% and 99.99%?
A tenfold reduction in allowed downtime. Three nines allows about 8.76 hours a year, while four nines allows about 52.6 minutes. The jump in cost and engineering effort is typically much larger than the jump in the number suggests.
Sources
- Google SRE Book: Availability Table
- Metabase: Uptime definition and tracking
- NASA: Availability, what is it?
- AWS Well-Architected: Availability
- IBM Documentation: The 9s
- Lane County: Service Availability
- Super User: Task Manager uptime numbers
- Microsoft Q&A: Should I turn off Fast Startup?