What the SLA Uptime Calculator does
An uptime target is a promise about downtime, stated backwards. 99.9% sounds close to perfect, but over an average month it allows 43 minutes and 50 seconds of outage; over a year, 8 hours and 46 minutes. This calculator turns a target into the downtime it permits for every common period, shows how much of that error budget an incident has already used, and works out the availability of a service built from several dependencies.
It is plain arithmetic done in your browser, with the period lengths stated rather than assumed - which matters more than it looks, because "a month" can mean 28, 30, 30.44 or 31 days depending on who wrote the contract.
How to use it
- Enter the uptime target, or pick one of the common targets. The allowed downtime for every period appears straight away.
- Choose the measurement period your SLA uses. If the contract says "per calendar month", use the 365.25/12-day month; if it says "30 days", use that one.
- Optionally enter the downtime you actually had and any scheduled maintenance. Tick the exclusion box if your contract excludes announced maintenance from the measured window.
- Read the error budget: how much of the permitted downtime is used, how much remains, and whether the period's SLA was missed.
- For a service that depends on others - a database, a payment provider, a CDN - open the composite section and list each component's availability to see what your service can realistically promise.
Reading the results
Allowed downtime is the whole budget for the period, not a per-incident allowance. A 99.9% monthly SLA is met by one 40-minute outage or by forty 1-minute blips - and missed by either plus a little more.
Error budget used is observed downtime divided by allowed downtime. Many teams slow down risky releases once it passes 75% and freeze them at 100%, which is the idea behind site reliability engineering's error-budget policy.
Observed availability is (measured time - downtime) / measured time for the one period you entered. It is not a forecast: a quiet month says little about the next one.
Worked example: a 99.9% monthly SLA with maintenance excluded
A SaaS provider promises 99.9% per 30-day month, excluding announced maintenance. This month it scheduled 4 hours of maintenance and had one unplanned outage of 50 minutes.
The month is 2,592,000 seconds. Removing 14,400 seconds of maintenance leaves a measured window of 2,577,600 seconds, and 0.1% of that is 2,577.6 seconds - 42 minutes 58 seconds of allowed downtime.
Fifty minutes is 3,000 seconds, so 116% of the error budget is used and the SLA is missed by about 7 minutes. Observed availability is 99.884%. Had maintenance counted against the SLA, the allowed downtime would have been 43 minutes 12 seconds, and the four hours of maintenance alone would have missed it several times over - which is why the exclusion clause matters.
Formulas and scoring rules
- Allowed downtime
allowed = measured_seconds x (1 - target / 100)measured_seconds is the period length, minus scheduled maintenance when it is excluded.- Error budget used
used = downtime / allowedAbove 1 means the SLA was missed. With a 100% target any downtime is an infinite overspend.- Observed availability
availability = (measured - downtime) / measured- Number of nines
nines = -log10(1 - target / 100)99.9% is 3 nines; 99.95% is about 3.3.- Composite, in series
A = A1 x A2 x ... x AnEvery component must be up. Two 99.9% components give 99.8001%.- Composite, in parallel
A = 1 - (1 - A1) x (1 - A2) x ... x (1 - An)Any one component is enough. Assumes failures are independent.- Period lengths
day 86,400 s; week 604,800 s; month 2,629,800 s (365.25/12 days) or 2,592,000 s (30 days); quarter 7,889,400 s; year 31,557,600 sResults are not rounded until display; tables show two decimals of minutes.
Why composite availability matters
A service cannot be more available than the things it cannot run without. If your application needs a database at 99.95% and a payment API at 99.9%, the best it can manage in series is about 99.85% - before any of your own outages. Offering customers 99.99% on top of that stack is a promise you have already broken on paper.
Redundancy is what lifts the ceiling: two independent 99.9% replicas in parallel reach 99.9999%. The catch is the word independent. Replicas in the same region, on the same deploy pipeline or behind the same DNS provider tend to fail together, and the real figure sits well below the formula.
Limitations: what the result does not prove
- It calculates what a target allows; it does not measure your uptime. For that you need monitoring, such as the Website Monitoring tool.
- Contracts define downtime differently - partial outages, degraded performance, minimum incident length, time zones. Read your SLA's definitions; the arithmetic here is only as good as the downtime figure you enter.
- Composite figures assume independent failures. Shared infrastructure makes real composite availability lower than the formula shows.
- A met SLA is not the same as happy users. Ten short outages at the busiest hour can hurt more than one long one at 3 a.m. that uses more of the budget.
Privacy: where your data goes
Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
Frequently asked questions
How much downtime does 99.9% uptime allow?
About 43 minutes 50 seconds per average month (365.25/12 days), 43 minutes 12 seconds per 30-day month, 10 minutes 5 seconds per week and 8 hours 46 minutes per year. The table above shows every period for whatever target you enter.
What is the difference between 99.9% and 99.99%?
One nine cuts allowed downtime by a factor of ten: from roughly 8.8 hours a year to 53 minutes. Each extra nine usually costs far more than the last, because it needs redundancy, faster detection and automated recovery rather than just fewer bugs.
Should scheduled maintenance count as downtime?
It depends on your contract. Many SLAs exclude maintenance that was announced in advance and kept within an agreed window; others count everything. Tick or untick the exclusion box to match your wording, and check whether there is a cap on how much maintenance can be excluded.
What is an error budget?
The error budget is the downtime your target permits in a period. Treating it as a budget turns reliability into a trade-off you can manage: while budget remains, the team can ship risky changes; once it is spent, the priority shifts to stability until the period resets.
Why are there two different months?
Calendar months vary from 28 to 31 days, so SLA tables use an average of 365.25/12 days (30.44). Some contracts instead say "30 days". The difference at 99.9% is only about 38 seconds, but it can decide a borderline breach, so the calculator offers both.
How do I calculate the availability of several services together?
If your service needs all of them, multiply their availabilities: that is the series figure. If any one of several redundant copies is enough, subtract each one's unavailability product from one: that is the parallel figure. Enter them in the composite section to see both.
Can an SLA be 100%?
You can write one, but it allows zero seconds of downtime, so the first blip breaches it and the error budget idea stops working. Most providers that advertise 100% actually mean a service credit scheme rather than a technical guarantee.
Last reviewed by the A2Z.Tools team against the sources listed above.
