Uptime & SLA Calculator
Convert an availability target into allowed downtime per day, month and year, track the error budget, and chain several services together.
Error budget
Combined availability
- Per day
- 1 min 26 s 86.4 s
- Per week
- 10 min 5 s 604.8 s
- Per month (30 days)
- 43 min 12 s 2,592 s
- Per quarter (90 days)
- 2 h 9 min 36 s 7,776 s
- Per year (365 days)
- 8 h 45 min 36 s 31,536 s
Periods are the ones published SLA tables use — a 30-day month, a 90-day quarter and a 365-day year — so these figures line up with a vendor’s table rather than with your calendar.
Error budget
- Budget for this period
- 43 min 12 s
- Used
- 12 min
- Remaining
- 31 min 12 s 72.222 % of the budget
- Availability so far
- 99.972222 % what the downtime above actually works out to
- Chained availability
- 99.7003 %
- Downtime per month (30 days)
- 2 h 9 min 28 s
- Downtime per year (365 days)
- 1 d 2 h 15 min
In series every component has to be up, so the availabilities multiply — a chain is always less available than its weakest link.
How Uptime & SLA Calculator works
An availability target is a share of a measurement period, and the figure anyone can act on is its complement: how much unavailability the target permits. Three nines over a 30-day month is 43 minutes 12 seconds; the same three nines over a 365-day year is 8 hours 45 minutes 57 seconds, and over a single day it is 1 minute 26 seconds. The percentage on its own means very little until the period is stated, which is why two contracts quoting the same number can promise wildly different things.
Treating that allowance as a budget rather than a boundary is what turns a number into a decision. A service targeting 99.9% over 30 days that has already spent 12 minutes has 31 minutes left, and the size of the remainder is the argument: budget in hand justifies shipping a risky change, a budget spent justifies freezing until reliability work lands. A team that never spends its budget is not being careful, it is over-provisioning against a target it should have raised.
Composing services changes the arithmetic in two opposite directions. Dependencies in series multiply, because every one of them has to be up for the request to succeed — three components at 99.9% give 99.7%, which is nearly three times the permitted downtime of any single one. Redundant paths compose as one minus the product of their failure probabilities, so two independent components at 99% give 99.99%. Real systems are both at once: serial tiers, each internally redundant, and the multiplication across tiers is what usually sets the achievable ceiling.
Precision matters more here than in most calculators, because the whole value of the output sits in its last digit. Five nines of a 365-day year is 315.36 seconds — a little over five minutes for a whole year — and computing that through a naive percentage as a floating-point fraction visibly wobbles the result. Working in whole seconds and dividing only at the end keeps the published figures exact, so the classic table of nines reproduces the values people expect to see rather than something a second or two off.
Reference
- downtime = period × (1 − availability)
- availability = 1 − downtime / period
- serial chain: A = a₁ × a₂ × … × aₙ
- redundant paths: A = 1 − (1 − a₁)(1 − a₂) … (1 − aₙ)
- error budget remaining = period × (1 − target) − downtime already spent
- day 86,400 s · week 604,800 s · 30-day month 2,592,000 s · 365-day year 31,536,000 s
How to use this calculator
State the target, or the downtime
Enter a percentage to see the unavailability it permits across every period, or enter an outage duration to see which target it just consumed. The conversion runs in both directions.
Pick the period that governs
Per day, per week, per 30-day month, per quarter and per 365-day year are shown together, because the contract, the dashboard and the on-call rota rarely agree on which one they mean.
Compose the dependencies
Add each component with its own availability and choose whether the group is a serial chain or a set of redundant paths, then read the combined figure and the downtime it implies.
Subtract what has been spent
Enter the minutes already burned in the current window to get the remainder, as both a duration and a share of the budget — the number a release decision actually turns on.
Worked examples
Three nines, three periods
- Given
- 99.9% availability
- Result
- 1 min 26 s per day · 43 min 12 s per 30-day month · 8 h 45 min 36 s per 365-day year
One target, three very different allowances. A contract that says 99.9% without naming its window has not said much.
A serial chain
- Given
- Load balancer, application and database, each at 99.9%
- Result
- 99.7% combined — 2 h 9 min 28 s per 30-day month
Availabilities multiply, so the chain is worse than its weakest link. Promising the customer the same number each component achieves is a promise the architecture cannot keep.
A redundant pair
- Given
- Two independent replicas, each at 99%
- Result
- 99.99% combined — 4 min 19 s per 30-day month
Only if the failures really are independent. Shared power, a shared control plane, or one bad deployment applied to both collapses the pair back towards a single component.
Five nines, annually
- Given
- 99.999% over a 365-day year
- Result
- 315.36 s — 5 min 15 s
Less than a single unattended reboot. At this level the constraint is no longer the software but how quickly a human can be woken, which is why five nines implies automated failover.
A budget part-spent
- Given
- 99.95% over 30 days, with 8 minutes of downtime already recorded
- Result
- 13 min 36 s of 21 min 36 s remaining — 63% of the budget left
Roughly two thirds through the window with roughly two thirds of the budget intact is the healthy shape. A budget spent in week one is the signal to stop shipping.
When to use it
- Checking whether a proposed SLA is achievable given the availability each dependency already publishes.
- Converting a monthly service credit threshold in a contract into the number of minutes support may actually lose.
- Deciding at a release meeting whether the error budget can absorb a risky migration this week.
- Sizing the redundancy a tier needs to hold its target once the serial multiplication across tiers is accounted for.
- Turning a postmortem’s outage duration into the share of the quarter’s budget it consumed.
Things to watch out for
- A month is taken as 30 days and a year as 365 unless stated otherwise. Contracts that use calendar months give a February allowance about 7% smaller than a July one, for the same percentage.
- Redundancy only multiplies as the formula says when the failure modes are independent. Correlated causes — a shared dependency, a simultaneous rollout, one rack — leave the pair no better than one component.
- Availability measures whether requests succeed, not whether they were fast. A service answering every request in nine seconds is fully available by this arithmetic and unusable in practice, so latency needs its own objective.
- Planned maintenance is excluded from most contractual SLAs and included in most internal objectives. Comparing a vendor’s published figure against your own measurement usually compares two different definitions.
- These are arithmetic conversions, not a prediction. Observed availability over a past window is a measurement; the same figure projected forward is a target with no guarantee attached.
Frequently asked questions
How much downtime does 99.9% allow?
Just under 44 minutes across a 30-day month, or 8 hours 46 minutes across a 365-day year. Per day it is 1 minute 26 seconds, which is why a single slow deployment can consume an entire day’s allowance on its own.
What is an error budget?
The unavailability a target permits, treated as a quantity to spend rather than a limit to avoid. It converts a reliability target into a release decision: budget remaining supports shipping changes, and an exhausted budget is the trigger to prioritise stability work.
Why is a chain of 99.9% services not 99.9% overall?
Because each dependency must be up simultaneously for a request to succeed, so their availabilities multiply. Three of them give 99.7%, and the permitted downtime roughly triples — the composite is always worse than its least reliable member.
Does adding a second replica double availability?
It squares the failure probability rather than doubling the success rate, which is a far larger gain: two independent components at 99% compose to 99.99%. The benefit disappears to the extent that both share a cause of failure.
What is the difference between an SLA, an SLO and an SLI?
The indicator is what gets measured, the objective is the internal target set on it, and the agreement is the contractual promise with financial consequences. Objectives are normally set tighter than the agreement so that missing one is a warning rather than a breach.
Should availability be measured per month or per year?
Whichever the commitment names, because the same percentage permits twelve times as much downtime annually as it does monthly. A yearly window also lets one long outage be absorbed, where a monthly window would have registered it as a miss.
Related DevOps tools
All devops tools- Kubernetes Resource Converter Convert CPU and memory quantities between every suffix Kubernetes accepts, and catch the ones that mean a billion times what you meant.
- YAML ↔ JSON Converter Convert either way with key order and comments-free fidelity, then see every scalar whose written form and parsed value disagree.
- .env File Converter Parse a dotenv file the way real readers do — quoting, escapes, comments — and retype it as JSON, YAML, docker flags, Compose, a Secret or a ConfigMap.
- htpasswd Generator Build Apache basic-auth lines with bcrypt, $apr1$, {SHA} or plain text, verify an existing hash, and collect several users into one file.
- Cron Expression Parser Read a cron line in plain English, expand every field, and see the next ten firings in local time and UTC.
- CIDR / Subnet Calculator Turn an IPv4 or IPv6 prefix into netmask, broadcast, usable range and host count — then split it, compare it, or aggregate a range.