What 99.9% uptime really means (with a downtime table)

99.9% sounds close to perfect, but it allows 43 minutes of downtime a month. Here's what each common uptime target allows, why your real uptime is lower than any one provider's, and how to pick an SLA you can keep.

October 2, 2026 · 5 min read · By the Spot Downtime team

“Three nines” sounds like a promise of near perfection. In practice, 99.9% uptime allows your service to be completely down for 43 minutes and 50 seconds every month, or almost nine hours a year. Whether that's acceptable depends on what your customers do when you're down, and on whether you even notice.

This guide translates uptime percentages into real time, explains why your actual uptime is lower than any single provider's, and shows how to pick a target you can keep.

The downtime table

Every uptime percentage is really a downtime budget: the amount of time you're allowed to be down in a given period. Here are the common targets (a month is an average month, 1/12 of a year):

Uptime	Per day	Per week	Per month	Per year
99%	14m 24s	1h 40m 48s	7h 18m 18s	3d 15h 39m
99.5%	7m 12s	50m 24s	3h 39m 9s	1d 19h 49m
99.9%	1m 26s	10m 5s	43m 50s	8h 45m 58s
99.95%	43s	5m 2s	21m 55s	4h 22m 59s
99.99%	9s	1m	4m 23s	52m 36s
99.999%	1s	6s	26s	5m 16s

Two things jump out:

Each extra nine is ten times harder. Going from 99.9% to 99.99% means cutting your monthly budget from about 44 minutes to about 4. That's the difference between “we fix it when we see it” and “it fixes itself before anyone notices.”
99% is not “almost always up”. It allows over seven hours of downtime a month, enough for a full working day of outages.

Uptime calculatorEnter any percentage, or work backwards from a downtime budget, and see what it allows per day, week, month, quarter and year.

Why your real uptime is lower than your provider's

Your hosting provider promises 99.95%. Your database provider promises 99.95%. Your payment provider, your DNS host, your email provider all make their own promises. The catch: if your product needs all of them to work, their downtime adds up.

When components are in series (every one must be up), you multiply their availabilities. Three services at 99.9% each give you 0.999 × 0.999 × 0.999 = 99.7%, roughly 2 hours 11 minutes of downtime a month instead of 44 minutes. Two at 99.9% already bring you down to 99.8%, or about 1 hour 28 minutes a month.

Rule of thumb

Your product can't be more available than the least available thing it depends on, and in practice it's less available than all of them combined. Promise less than your weakest dependency.

That's also why high-availability systems lean on redundancy: two independent servers behind a load balancer fail together far less often than either one alone.

Downtime you don't see still counts

An uptime percentage is only as good as the monitoring behind it. If nobody checks your site, a 20-minute outage at 3 a.m. simply never happened, as far as your reports are concerned, but your customers in another time zone saw it.

How often you check also sets how much of an outage you can miss and how quickly you can react:

Checking every 5 minutes means an outage can run for up to 5 minutes before anyone knows, and shorter outages can slip between checks entirely.
Checking every minute catches most outages within a minute or two.
Checking every 30 seconds is what you want when your budget is measured in minutes, for example at 99.95% and above.

A practical guide: if your monthly budget is 44 minutes, losing five of them before you even get an alert is a meaningful slice. Match your check interval to how tight the budget is.

What actually counts as “down”?

Before you promise a number, decide what you're measuring. Common traps:

Up, but useless

Your homepage returns 200 OK while the login form throws an error, or the page loads but shows an empty “something went wrong” message. A plain “is it responding?” check calls that up. Add a keyword check (the page must contain text that only appears when it works) or check an API endpoint that exercises the database.

Slow is the new down

A page that takes 30 seconds to load is, for your visitors, down. Track response time alongside uptime, and treat a sustained slowdown as an incident.

Planned maintenance

Most SLAs exclude scheduled maintenance announced in advance. If yours does, say so explicitly, announce maintenance on your status page, and pause monitoring during the window so it doesn't count against you or wake anyone up.

Partial outages

If one region, one feature or one customer segment is down, are you down? Decide up front, and monitor each critical piece separately so you can tell.

How to choose an uptime target you can keep

Measure first. Monitor for a month or two before you promise anything. Your current track record is the most honest starting point. In Spot Downtime, Download logs on any monitor gives you a daily uptime CSV to work from.
Multiply your dependencies. Write down every service your product can't run without, multiply their published availabilities, and stay below the result.
Ask what downtime costs. An internal tool can live with 99.5%. A checkout page that loses sales every minute it's down justifies the engineering for 99.95%.
Leave headroom. If you reliably achieve 99.95%, promise 99.9%. An SLA you break every quarter is worse than a slightly lower one you always meet.
Publish it. A public status page with your uptime history turns a number in a contract into something customers can see and trust.

The short version

99.9% uptime = about 44 minutes of downtime a month, or 8h 46m a year.
Each extra nine cuts the budget by ten.
Dependencies multiply: three services at 99.9% give you about 99.7%.
You can only count downtime you detect: check often enough for your budget, and check that pages actually work, not just respond.

Want to know your real number? Start monitoring for free and in a month you'll have an honest uptime figure, a response-time history, and a public status page to share it.