Uptime and SLA Calculator
Turn a number of nines into minutes of allowed downtime, then check whether your dependencies can actually support the promise you are making.
Your availability target
The percentage of time the service is expected to be up.
99.9% allows
43m
of downtime in a 30-day month
Allowed downtime by period
| Period | Allowed downtime | In minutes |
|---|---|---|
| Per day | 1.4m | 1.4 |
| Per week | 10m | 10.1 |
| Per 30-day month | 43m | 43.2 |
| Per quarter | 2h 11m | 131.4 |
| Per year | 8h 46m | 525.6 |
Every additional nine divides these numbers by ten. That is the part people skip when they promise a fourth nine in a meeting: the failure has not changed, but the time you have to detect it, page someone, diagnose it and ship a fix has dropped from 43 minutes a month to 4.
Error budget
The same target, expressed as failures you are allowed to spend rather than time you must avoid.
Failures allowed
50K
Requests that may fail this month.
Budget used
28%
Budget left
31m
Burn rate
0.83×
Above 1× means you finish the month over budget.
You are under budget with 31m left. An error budget is meant to be spent, not hoarded: consistently finishing the month at 20% used usually means the team is shipping too slowly, not that the service is unusually good.
Key takeaways
- An availability target converts to downtime by multiplying the period by one minus the target: 99.9% over 30 days allows 43.2 minutes of downtime, and 99.99% allows 4.32 minutes.
- Each additional nine cuts the allowed downtime by a factor of ten, so going from 99.9% to 99.99% means the same failure must be detected and resolved ten times faster.
- Availability of services in series multiplies, so a system depending on five components at 99.9% each can be no better than 99.5% overall, no matter how reliable its own code is.
- Redundancy inverts the maths: two independent replicas each at 99% give 99.99% combined, because both must fail at once, which is why redundancy beats reliability engineering on any single component.
- An error budget is the inverse of the SLO expressed in requests: 99.9% of 100 million monthly requests allows 100,000 failures, which is a spending limit rather than a target to avoid.
Frequently asked questions
- How much downtime does 99.9% uptime allow?
- About 43.2 minutes per 30-day month, 8.76 hours per year, or 10.1 minutes per week. The general formula is the length of the period multiplied by one minus the availability target, so 30 days × 0.001 = 0.03 days = 43.2 minutes.
- What is the difference between an SLA, an SLO and an SLI?
- An SLI is the measurement (the percentage of requests that succeeded), an SLO is the internal target you hold yourself to, and an SLA is the external contract with financial consequences when you miss it. The SLO should always be stricter than the SLA, typically by an order of magnitude of error budget, so that you start responding well before a customer becomes entitled to a refund.
- How do you calculate availability across multiple dependencies?
- For components in series, where any one failing takes the system down, multiply their availabilities together. Three services at 99.9% give 0.999³ = 99.7%. For redundant components in parallel, where all must fail to take you down, multiply their failure probabilities instead: two at 99% give 1 − 0.01² = 99.99%.
- What is an error budget and how should teams use it?
- An error budget is the amount of unreliability an SLO permits, expressed as failed requests or minutes of downtime. It exists to be spent: a team with budget remaining should be shipping faster and taking more risk, and a team that has exhausted it should freeze feature work and spend the time on reliability. It converts an argument about caution into an arithmetic question.
- Is five nines a realistic target?
- Rarely, and almost never for a system a small team operates. 99.999% allows 5.26 minutes of downtime a year, which is less time than most on-call engineers need to read a page and open a laptop, so it requires automated failover with no human in the loop, multi-region redundancy, and a deployment process that cannot itself cause an outage. Most products are better served by an honest 99.9% than an aspirational 99.999% nobody measures.