How the calculator works
Allowed downtime is the length of the period multiplied by 100% minus your target. The calculator applies that to a day, a week, a 30-day month, a 90-day quarter and a 365-day year, and accepts up to three decimal places, so 99.999% works. These are the common targets:
| Target | Per week | Per 30-day month | Per year |
|---|---|---|---|
| 99% | 1h 40.8m | 7h 12m | 3d 15h 36m |
| 99.5% | 50.4m | 3h 36m | 1d 19h 48m |
| 99.9% | 10.1m | 43.2m | 8h 45.6m |
| 99.95% | 5m | 21.6m | 4h 22.8m |
| 99.99% | 1m | 4.3m | 52.6m |
| 99.999% | 6 sec | 25.9 sec | 5.3m |
Why the extra nine costs so much
Each additional nine reduces your allowed downtime by a factor of ten. Going from 99.9% to 99.99% sounds like a rounding difference in a contract, but it takes your monthly budget from roughly 43 minutes down to about 4 minutes.
Four minutes a month is less time than most teams take to acknowledge a page, let alone diagnose and fix. That is why high-nines targets are less about better software and more about automated failover, because no human response loop fits inside the budget.
Downtime budgets are a planning tool
The useful way to read the number this calculator gives you is as a monthly allowance you are choosing how to spend. Planned maintenance, risky deploys, and infrastructure migrations all draw from the same account as genuine incidents.
Teams that track this deliberately — often called an error budget — get a concrete answer to a question that is otherwise political: should we ship the risky change this week? If the budget is already spent, the answer is no.
Do not publish an SLA target until you have measured your actual availability for at least a quarter. Committing to a number you have never hit turns an engineering problem into a contractual one.
What counts as downtime
This is where most SLA disputes come from. Define, in writing, whether a partial outage counts, whether degraded-but-responding counts, whether a regional failure affecting some users counts, and whether announced maintenance windows are excluded. Two parties reading the same percentage can arrive at very different bills.
A worked example: dependencies multiply
Your service can never be more available than the things it needs. If your API runs on a host with a 99.95% target and depends on a database with a 99.9% target, and either failing takes you down, the best you can expect is 99.95% × 99.9% ≈ 99.85%. That is about 65 minutes a month, not the 43 minutes a 99.9% promise allows. Before you commit to a number, multiply the targets of everything in the request path, then leave room for your own deploys and mistakes.
The reverse also helps: two independent copies of a 99.9% component, where either one is enough, fail together far less often than either alone. That arithmetic is why redundancy, not faster humans, is how teams reach four nines.
Measuring the number you promised
Uptime from a monitoring tool is usually measured as the share of checks that passed, not as wall-clock time. A failed check stands in for the time until the next one, so a shorter check interval gives a more precise figure, and an outage shorter than the interval can be missed entirely. If you promise 99.99% (about 4 minutes a month), checking every 5 minutes cannot tell you whether you kept it. SutramX explains exactly how it counts degraded checks, paused time and maintenance in its uptime math, and SLO tracking with error budgets and burn rates is part of reliability insights.
For our own service, SutramX publishes a 99.9% monthly uptime target on Growth and Pro, with service credits on request: see the uptime target. For the difference between the terms, read SLA, SLI and SLO explained and what uptime really measures. To see how fast a budget is being spent, try the error budget calculator.
Frequently asked questions
How is allowed downtime calculated?
Multiply the length of the period by the share of time you are allowed to be down, which is 100% minus the target. For 99.9% over a 30-day month that is 43,200 minutes × 0.1% = 43.2 minutes.
Does the calculator use calendar months?
No. A month here is 30 days, a quarter 90 days and a year 365 days. Many contracts use the calendar month instead, so 99.9% of a 31-day month allows 44.6 minutes and of February 40.3 minutes. Check which your agreement uses.
What is the difference between an SLA, an SLO and an SLI?
An SLI is the measurement, such as the share of successful checks. An SLO is the internal target for it, such as 99.95%. An SLA is the promise made to customers, usually looser than the SLO and backed by credits if it is missed.
Does planned maintenance count as downtime?
Only if your agreement says so. Many SLAs exclude announced maintenance, often with a notice period and a monthly cap. Whatever you choose, write it down before the first dispute, not during it.