SLA Uptime Calculator
Calculate allowed downtime based on SLA uptime percentage.
- Per year
- 8.8 h
- Per month (30d)
- 43.2 min
- Per week
- 10.1 min
- Per day
- 1.4 min
Overview
Availability targets are quoted as percentages, and percentages are bad at conveying scale. 99% and 99.9% look adjacent and differ by more than three days a year. This calculator turns the percentage into time, which is the form the number is actually useful in.
Enter an availability figure and you get the permitted downtime for a year, a month, a week and a day.
How to use
- Enter an availability percentage, or click a preset.
- Read the permitted downtime across the four windows.
The presets cover the tiers that appear in real agreements: 90, 95, 99, 99.9, 99.95, 99.99 and 99.999.
The reference table
| Availability | Per year | Per month (30d) | Per week | Per day |
|---|---|---|---|---|
| 90% | 36.50 days | 3.00 days | 16.8 h | 2.4 h |
| 95% | 18.25 days | 1.50 days | 8.4 h | 1.2 h |
| 99% | 3.65 days | 7.2 h | 1.7 h | 14.4 min |
| 99.9% | 8.8 h | 43.2 min | 10.1 min | 1.4 min |
| 99.95% | 4.4 h | 21.6 min | 5.0 min | 43.2 s |
| 99.99% | 52.6 min | 4.3 min | 1.0 min | 8.6 s |
| 99.999% | 5.3 min | 25.9 s | 6.0 s | 864 ms |
Two things are worth noticing. The daily column is what a single bad deploy has to fit inside. And below about 99.99%, the permitted downtime for a day is shorter than the time it typically takes a human to notice an alert, open a dashboard and decide what to do — which is the practical boundary where reliability stops being an operational problem and becomes an architectural one.
Choosing a target
Work backwards from consequences, not forwards from ambition.
Ask what happens during the outage. If a batch job runs late and catches up, the target can be low. If a customer cannot complete a purchase, the target follows revenue. If an emergency service depends on it, the target is not really the question you are asking.
Then check the target against your dependencies. Availability composes multiplicatively for anything in series: a service that needs three components, each at 99.9%, has a ceiling of about 99.7% before it has done anything wrong itself. You cannot promise more than your critical path allows, and adding a retry does not change the arithmetic unless the failures are independent.
Finally, check it against your recovery process. A target of 99.99% with a manual failover and an on-call rotation that pages by email is not a target, it is a wish. The number implies the mechanism.
SLO and SLA are different numbers
Keep the internal SLO tighter than the contractual SLA. The gap is your operating margin: the region where you have missed your own target and started reacting, but have not yet incurred a penalty.
A 99.9% internal SLO behind a 99.5% contractual SLA gives roughly 2.9 hours of slack per month between the first signal (43 minutes) and the first invoice credit (3.6 hours). If the two figures are equal, the moment you notice is also the moment you owe money, which removes any chance of handling the problem quietly.
Also read the exclusions. Most SLAs do not count announced maintenance, failures caused by the customer’s own configuration, or force-majeure events. Those carve-outs mean a service can meet its SLA in a month where users experienced real unavailability — which is a legal outcome, not an engineering one.
Deciding what counts as down
The percentage is arithmetic; the hard part is the definition it applies to. Two teams can report different availability for the same month without either lying.
Measured from where? A check from inside your own network skips the CDN, the DNS, and the internet path — which is where a large share of user-visible failures happen. Measuring from outside gives a number closer to what users experienced and worse than the one your dashboard shows.
Measured how often? A probe every five minutes cannot detect an outage shorter than five minutes, and it attributes a 30-second outage either zero or five minutes of downtime depending on timing. Coarse probing does not make you more reliable; it makes your measurement less able to see.
Which endpoint? A health check that returns 200 whenever the process is running will report full availability through an outage where every real request failed. The check has to exercise the dependencies that matter.
Partial failure. If one endpoint in twenty is broken, is the service up? A time-based definition usually says yes. Users of that endpoint say no. This is the main reason to define availability as a ratio of successful requests rather than as intervals of uptime — see the error budget calculator for that framing.
Write the definition down before you commit to the number, because the definition is where the disagreement will happen later.
Examples
- Justifying redundancy. 99.9% permits 43 minutes a month; a single-region deployment with a manual failover routinely spends more than that on one incident.
- Sizing a maintenance window. A four-hour window is over budget for anything at 99.9% or better if it counts as downtime. Either it does not count, contractually, or you need a zero-downtime migration.
- Sanity-checking a vendor promise. A 99.99% claim with no automated failover described anywhere in the documentation is a marketing number.
- Setting an alert threshold. At 99.95%, one minute of downtime per week is a fifth of the weekly budget. That is the scale your alerting has to resolve.
Notes
A year is 365 days and a month is 30 days here. Leap years and calendar months shift the figures slightly; if a contract turns on the difference, use the definition written in the contract.
This tool answers “how much downtime does this percentage allow”. If you also want to know how many individual failed requests fit in the budget, and how much of it you have already spent, use the error budget calculator — that is the same arithmetic applied to request volume rather than to time.