CalcToolVault

Uptime & SLA Calculator

Convert an SLA percentage into the downtime it actually permits per day, month and year — and see what chaining dependencies does to it.

Your details

Services that must all be up for yours to be up. Their availabilities multiply.

min/mo

Most SLAs exclude scheduled windows from the downtime budget

This calculator runs entirely on your device. Nothing you enter is uploaded, stored, or sold. How this works

Allowed downtime per month

43.8 min

At 99.9000% availability

Save these results

Includes your inputs, the full breakdown, and every row of the table.

Per day

1.4 min

Per week

10.1 min

Per year

8.8 hr

Effective availability

99.9000%

Breakdown
Target availability
99.9000%
Dependencies in series
1
Total monthly outage budget
43.8 min
Downtime allowed at each availability target
AvailabilityPer dayPer monthPer year
90% (one nine)2.4 hr3.0 days36.5 days
95%1.2 hr1.5 days18.3 days
99% (two nines)14.4 min7.3 hr3.7 days
99.5%7.2 min3.7 hr1.8 days
99.9% (three nines)1.4 min43.8 min8.8 hr
99.95%43.2 s21.9 min4.4 hr
99.99% (four nines)8.6 s4.4 min52.6 min
99.999% (five nines)864 ms26.3 s5.3 min

What this means

  • Add your upstream dependencies to see why a single service's SLA is not the number your users experience.
  • This is the contractual allowance, not a prediction. Most SLAs pay out service credits rather than real damages, so the number matters more for architecture decisions than for compensation.

How the uptime & sla calculation works

An SLA percentage is an abstraction that hides how little downtime it actually buys you. Three nines sounds robust until you convert it: 99.9% permits about 43 minutes of outage per month, which a single bad deploy can consume. Four nines leaves roughly four minutes — less than most teams take to notice an incident, let alone page someone and roll back.

The part that catches teams out is that availability multiplies. If your service depends on a database, an auth provider and a payment gateway, each at 99.9%, your ceiling is 99.9% to the fourth power — about 99.6%, or nearly three hours a month — before your own code fails at all. Adding dependencies quietly lowers your maximum achievable availability, which is why the dependency count is the most important field here.

Frequently asked questions

Why does adding dependencies reduce availability so fast?

Because every component in series must be up simultaneously, the probabilities multiply rather than average. Ten services at 99.9% each give a combined 99.0%, which is seven hours of downtime a year instead of forty-three minutes a month. Redundancy is the only way to reverse this, since parallel components multiply their failure probabilities instead.

Does planned maintenance count against the SLA?

Usually not. Most commercial SLAs exclude scheduled windows announced in advance, which is why a provider can claim 99.99% while taking regular maintenance outages. Use the exclusion field to model your real total unavailability rather than just the contractual portion.

What availability should I actually target?

Higher targets get expensive very quickly, and the cost curve is steeper than the benefit curve for most products. Rather than picking a number that sounds impressive, work out what an hour of downtime genuinely costs you and buy availability up to the point where the next nine costs more than the outages it prevents.

Related calculators

Spotted a problem, or want this calculator to do more?Corrections are fixed first, and the most-requested features get built next.Tell us →

Disclaimer. This calculator is provided for general information and educational purposes only and does not constitute financial, tax, legal, medical, or engineering advice. Results are estimates based on the inputs you provide and the assumptions described above. Confirm any figure with a qualified professional before acting on it.