Blog
Exact downtime budgets for 99% to 99.99% uptime per day, month and year, plus how check intervals, maintenance windows and dependencies change what you can promise.
99.9% uptime allows 43 minutes and 12 seconds of downtime per 30-day month, about 1 minute 26 seconds per day and 8 hours 45 minutes per year. On a 31-day month the 99.9 uptime downtime per month budget grows to 44 minutes 38 seconds, and on a 28-day February it shrinks to 40 minutes 19 seconds. The number you can actually promise also depends on how often you check, whether maintenance is excluded and what your service depends on.
This guide gives the exact budgets for the common targets, shows how to calculate your own and explains which details in an SLA decide whether you meet it.
An uptime percentage is a fraction of a time period. 99.9% means 0.1% of the period may be unavailable. Since months differ in length, the allowed downtime differs too:
Most SLAs measure per calendar month, so your real budget changes every month. If you plan around 43 minutes, February is the month that bites.
The period also matters more than people expect. A yearly 99.9% target allows 8h 45m in total, which means one bad month with a 3-hour outage can still be absorbed. A monthly 99.9% target does not forgive that: the same outage breaches the SLA for that month, no matter how clean the other eleven were.
Here are the allowed downtimes for the five targets you will see most often, based on a 30-day month and a 365-day year:
SLO per day per 30-day month per 365-day year 99% 14m 24s 7h 12m 3d 15h 36m 99.5% 7m 12s 3h 36m 1d 19h 48m 99.9% 1m 26s 43m 12s 8h 45m 36s 99.95% 43s 21m 36s 4h 22m 48s 99.99% 8.6s 4m 19s 52m 34s
Each additional nine divides the budget by ten. Going from 99.9% to 99.99% does not mean being a bit more careful. It means going from "one incident with a manual fix fits into the month" to "a single deploy rollback eats the whole budget".
A practical way to read the list:
The formula is simple:
allowed_downtime = period_in_seconds * (1 - SLO / 100)
A one-liner for the shell, here for 99.9% over 30 days:
awk -v slo=99.9 -v days=30 'BEGIN { s = days*86400*(1-slo/100); printf "%.0f s = %.1f min\n", s, s/60 }'
# 2592 s = 43.2 minChange days to 31, 28 or 365 to get the other periods. The remaining budget at any point in the month is your error budget: what is left after subtracting the downtime that already happened. If the terms SLA, SLO, SLI and error budget blur together, the monitoring glossary with definitions of SLA, SLO and error budget separates them cleanly.
Your uptime figure is only as precise as your measurement. With external checks, downtime is recorded in steps of the check interval, and that has three effects.
With a 1-minute interval, the 43-minute budget at 99.9% equals about 43 failed checks. With a 5-minute interval, it equals about 8. At 99.99%, the monthly budget of 4m 19s is smaller than a single 5-minute interval: if one failed check is counted as a full interval of downtime, one blip breaches the month.
A useful rule of thumb: the monthly budget should hold at least ten check intervals. That makes 1-minute checks sufficient for 99.9%, borderline for 99.95% and too coarse for 99.99%, where you would need checks every 25 seconds or switch to request-based measurement.
An outage shorter than the interval can fall entirely between two checks. Your dashboard shows 100%, while customers saw errors. That is not a problem for your SLA report, but it is a problem if a customer measures more finely than you do and disputes your number.
To avoid false alarms, most setups require several consecutive failures or confirmation from multiple regions before declaring an outage. That is the right call, because a single probe with a bad network route should not burn your budget. But it means you need to define in the SLA whether downtime starts at the first failed check or at confirmation. With a 1-minute interval and two required failures, the difference is up to two minutes per incident, which is almost 5% of a 99.9% monthly budget.
Scheduled maintenance is the biggest lever in any SLA. Take a team that needs 4 hours of maintenance per month:
Excluding maintenance is standard and fair, but only with conditions attached: announced a fixed time in advance, published where customers look, limited in total duration per month, and ideally in a low-traffic window. Without those conditions, "maintenance" becomes a label you can put on any outage, and customers will read your SLA that way.
One more trap: maintenance that overruns. Decide upfront that anything beyond the announced end time counts as regular downtime. It keeps planning honest.
If your service needs several components to work and each fails independently, their availabilities multiply. Three hard dependencies at 99.9% each give 0.999 * 0.999 * 0.999 = 99.7%, which is about 129 minutes per month instead of 43.
So before promising 99.9%, list everything in the request path: load balancer, application, primary database, cache if it is not optional, DNS, the payment or auth provider. If any single one of them is weaker than your target, your target is not reachable without redundancy or graceful degradation. An uptime percentage is only meaningful together with its period, its measurement method and its exclusions, and you should promise less than your weakest dependency allows.
Keep two numbers apart. The SLO is your internal target and the one you alert on. The SLA is the contractual promise with consequences, and it should be looser. A common pattern is an internal SLO of 99.95% with an external SLA of 99.9%, which gives you 21 minutes of margin each month before credits are due.
A good SLA answers these questions explicitly:
A clause you can adapt:
Monthly Uptime Percentage = (total minutes in the calendar month - excluded minutes - downtime minutes) / (total minutes in the calendar month - excluded minutes) x 100. A minute counts as downtime when [service endpoint] fails availability checks from at least two monitoring regions. Excluded minutes are scheduled maintenance announced at least [72] hours in advance on [status page URL], limited to [4] hours per month. If the Monthly Uptime Percentage falls below 99.9%, the customer receives a credit of [X]% of the monthly fee; below 99.0%, [Y]%. Credits must be requested within [30] days after the end of the month.
During an incident, customers check whether you are still within your promise long before the monthly report arrives. Clear communication matters as much as the number, which is why it helps to have a routine for writing incident status updates at every stage.
Whatever tool you use, the measurement setup should match the SLA wording: same endpoints, an interval fine enough for your target, multi-region confirmation and maintenance windows recorded where the calculation can exclude them.
In m0nitor, uptime checks for websites, APIs and servers run on a fixed interval from distributed probes in several regions, and an outage is only confirmed when multiple locations agree, so a single-route network blip does not count against you. Scheduled maintenance windows and incident timelines document planned and unplanned downtime, and a public status page with incident history gives customers the place where maintenance is announced, which is exactly what the exclusion clause above refers to.
99.9% uptime allows 8 hours, 45 minutes and 36 seconds of downtime in a 365-day year. A yearly target is more forgiving than a monthly one because a single long outage can be offset by quiet months.
99.9% allows 43m 12s of downtime per 30-day month, 99.99% only 4m 19s. The tenfold difference usually means moving from human-handled incidents to automatic failover and rollbacks.
Only if your SLA says so. Most SLAs exclude maintenance that is announced in advance and limited in duration, and count any overrun beyond the announced window as regular downtime.
For many small and mid-sized SaaS products it is a realistic and honest target, because one incident per month with a manual fix still fits. Check your dependencies first: if one of them is below 99.9%, promise less or add redundancy.