How much downtime is 99.9% uptime per month?

About 43 minutes and 50 seconds in an average 30.44-day month, or roughly 10 minutes per week.

For most production websites, no. 99% allows more than 7 hours of downtime a month, which visitors and search engines will notice. It can be acceptable for internal tools or hobby projects.

How do I calculate uptime percentage?

Divide the time the service was up by the total time in the period and multiply by 100. For example, 2 hours of downtime in a 30.44-day month gives (730.56 - 2) / 730.56 x 100 = 99.73%.

Can a monitor with 5-minute checks prove 99.99% uptime?

Not precisely. 99.99% allows only about 4 minutes 23 seconds of downtime per month, which is shorter than one 5-minute check interval, so short outages can be missed or over-counted. Use 1-minute checks or server-side metrics for that level.

Uptime Percentage Explained (99.9% vs 99.99% in Minutes)

Uptime percentage tells you what fraction of a given period a service was reachable and working. The quick answer most people want: 99.9% uptime ("three nines") allows about 43 minutes 50 seconds of downtime per month, and 99.99% ("four nines") allows about 4 minutes 23 seconds. Every additional nine divides the allowed downtime by ten, which is why each one is dramatically harder and more expensive to achieve than the last.

The formula

uptime % = (total time - downtime) / total time x 100
allowed downtime = total time x (1 - uptime % / 100)

The only thing that changes between calculations is the length of the period. This article uses:

Year: 365 days (31,536,000 seconds)
Month: 30.44 days, the average length of a month over a year (365.25 / 12, rounded)
Week: 7 days
Day: 24 hours

If your SLA defines a month as the actual calendar month, February will allow a little less downtime and 31-day months a little more.

Allowed downtime table

Uptime	Per year (365 d)	Per month (30.44 d)	Per week	Per day
99%	3 d 15 h 36 min	7 h 18 min 20 s	1 h 40 min 48 s	14 min 24 s
99.5%	1 d 19 h 48 min	3 h 39 min 10 s	50 min 24 s	7 min 12 s
99.9%	8 h 45 min 36 s	43 min 50 s	10 min 5 s	1 min 26 s
99.95%	4 h 22 min 48 s	21 min 55 s	5 min 2 s	43 s
99.99%	52 min 34 s	4 min 23 s	1 min 0 s	8.6 s
99.999%	5 min 15 s	26 s	6 s	0.86 s

Values are rounded to the nearest second (or tenth of a second where the number is very small). To try other targets or periods, use the uptime calculator.

Checking the math yourself

You can reproduce any row with a one-liner. For 99.95% over a 30.44-day month:

python3 -c "print((1 - 0.9995) * 30.44 * 86400)"
# 1315.008  -> 21 min 55 s

What each level means in practice

99% (two nines). More than seven hours a month. A single bad deploy on a Friday evening that nobody notices until Saturday morning uses this up. Fine for a side project, not for a store or SaaS.

99.5%. Around three and a half hours a month. A realistic floor for a small business site on shared hosting with no redundancy.

99.9% (three nines). The most common target in hosting and SaaS agreements. You get roughly 43 minutes a month: enough for one moderate incident, or a few short restarts, but not both.

99.95%. About 22 minutes a month. Usually requires at least two application servers behind a load balancer and deploys that do not take the site offline.

99.99% (four nines). Under five minutes a month. A human cannot be paged, wake up, log in and fix something in that time, so this level depends on automatic failover, health checks and rolling deploys.

99.999% (five nines). 26 seconds a month. Typically claimed for telecom and core infrastructure, and very hard to achieve for an application that depends on a database, a payment provider and a CDN.

Combining components: why your real uptime is lower

If a request has to pass through several components in series, and each can fail independently, the overall availability is the product of their availabilities.

Component	Availability
CDN	99.99%
Application servers	99.95%
Database	99.9%
All three in series	99.84%

0.9999 x 0.9995 x 0.999 = 0.9984, which is roughly 70 minutes of possible downtime per month. That is worse than any single component.

Redundancy works the other way. Two independent servers that are each 99% available, either of which can serve traffic, give 1 - (0.01 x 0.01) = 99.99%. The catch is the word independent: two servers in the same data center sharing a power feed or a database are not independent, and the real number will be lower.

SLA, SLO and SLI

These terms are often mixed up:

SLI (service level indicator): the measurement itself, for example "percentage of successful checks of the homepage".
SLO (service level objective): your internal target, for example "99.9% over a rolling 30 days".
SLA (service level agreement): a contract with customers that says what happens, usually service credits, if you miss a stated level.

A sensible practice is to set your SLO slightly stricter than any SLA you publish, so you notice trouble before it costs you money.

Error budgets

The allowed downtime is often called an error budget. If your SLO is 99.9% per month, you have about 43 minutes to "spend". If a migration already used 30 minutes this month, the team might postpone risky changes until the window resets. Thinking of downtime as a budget turns an abstract percentage into a planning tool.

How uptime is measured

The percentage is only as accurate as the measurement behind it. Things to check before you trust a number:

Check interval. A monitor that checks every 5 minutes cannot see an outage shorter than 5 minutes reliably, and one failed check is usually counted as a full interval of downtime. For 99.99% targets, where the monthly budget is 4 minutes 23 seconds, you need 1-minute checks at minimum, plus server-side metrics.
What counts as "down". A timeout and a 5xx response are clearly down. What about a 200 response that shows an error message, or a page that takes 20 seconds to load? Decide and write it down. A keyword monitor catches the "200 but broken" case.
Where you measure from. A check from a single location can report a network problem between the checker and your server as an outage. Re-checking from a second location before declaring the site down avoids many false alarms.
Maintenance. Many SLAs exclude announced maintenance. If yours does, record maintenance periods so you can subtract them, and say so on your status page.
Which endpoints. Measuring only the homepage can hide a broken checkout or API. Monitor the paths that matter to customers.

PingRobot, for example, checks every 5 minutes on the free plan and every minute on Pro, and re-checks failures from a second region before alerting, which addresses points 1 and 3. Whatever tool you use, know its interval before quoting a percentage.

Choosing a realistic target

A practical way to pick a number:

Personal site, internal tool: 99% to 99.5%.
Small business site, agency client sites: 99.9% is a reasonable promise if hosting is decent and someone receives alerts.
SaaS product, ecommerce: 99.9% to 99.95%, backed by redundancy and fast alerting.
Infrastructure that other businesses build on: 99.99% and up, with automatic failover.

Do not promise a level you cannot measure. If your monitoring resolution is 5 minutes, a 99.99% claim is not something you can verify.

Quick reference

99.9% = 43 min 50 s per month, 8 h 45 min 36 s per year
99.99% = 4 min 23 s per month, 52 min 34 s per year
Components in series multiply; redundancy helps only when failures are independent
Your measured uptime depends on check interval, location and the definition of "down"

To learn how monitoring works end to end, read what is uptime monitoring.

Start monitoring free — 10 monitors, no credit card.