Uptime SLA Calculator
Convert an SLA uptime percentage into allowed downtime per year, month and day — for any value like 99.97%.
Formula last reviewed 4 August 2026 · How we verify our calculators
Allowed downtime / year
8.76 hrs (525.6 min)
- Per month
- 43.8 min
- Per day
- 1.44 min
Updates live as you type
Frequently asked questions
It is the share of time a service guarantees to be available. The rest is allowed downtime. 99.9% ("three nines") permits about 8.76 hours of downtime per year.
Multiply total time by (1 − uptime%). A year has 525,600 minutes, so 99.9% allows 525,600 × 0.001 = 525.6 minutes (~8.76 hours) of downtime.
Each extra nine cuts downtime roughly tenfold: 99% ≈ 3.65 days/yr, 99.9% ≈ 8.76 hrs, 99.99% ≈ 52.6 min, 99.999% ≈ 5.26 min.
Usually not. SLAs often exclude scheduled maintenance and force majeure, and breaching one typically yields service credits rather than full compensation. Read the specific terms.
What 99.9% actually permits
An SLA of 99.9% allows 8.76 hours of downtime a year — 43.8 minutes a month, or 1.44 minutes a day. Written as a percentage it sounds close to perfect. Written as "your service may be down for the better part of a working day each year, and you have no contractual claim," it reads differently.
That translation is the entire purpose of this calculation, and it is the number to have in front of you when signing or offering a service agreement.
How allowed downtime is derived
Allowed downtime = period length × (1 − uptime ÷ 100)
For 99.9% over a year: 365 × 24 × 60 = 525,600 minutes. Multiply by 0.001 to get 525.6 minutes, which is 8.76 hours.
The relationship is not linear in a way intuition handles well. Each additional nine divides the allowed downtime by ten:
- 99% (two nines) — 3.65 days a year
- 99.9% (three nines) — 8.76 hours
- 99.95% — 4.38 hours
- 99.99% (four nines) — 52.6 minutes
- 99.999% (five nines) — 5.26 minutes
The step from three nines to four removes roughly eight hours of annual allowance, and the engineering cost of that step is typically far more than proportionate — it generally requires removing every single point of failure, automating failover, and eliminating maintenance windows.
What an SLA actually is
This is the part most often misread. An SLA is a commercial document, not an engineering guarantee. It does not promise the service will stay up; it specifies what you are owed if it does not.
The remedy is almost always a service credit — a percentage of that month's fee, typically 10% to 25%, applied against future billing. It is capped at what you paid, it does not cover your consequential losses, and on a $200 monthly bill a breach might return $20 against an outage that cost your business considerably more.
Several details routinely narrow the commitment further:
Scheduled maintenance is usually excluded, so announced downtime does not count against the figure at all.
The measurement window matters. Monthly measurement is more favourable to the customer than annual, because a single bad month cannot be diluted by eleven good ones.
You normally have to claim. Credits are rarely automatic; most providers require a claim within a defined window, and unclaimed credits are simply not paid.
Exclusions typically cover force majeure, customer-caused issues, third-party network problems and anything outside the provider's direct control.
Composing services
Availability multiplies across dependencies in series. A system built on three components each at 99.9% has a theoretical combined availability of 0.999³ = 99.7%, or about 26 hours of annual downtime — worse than any single component.
This is why adding a dependency for resilience can reduce overall availability if it introduces a new failure mode, and why redundancy has to be genuinely parallel to help rather than merely present.
Common mistakes
Reading an SLA as a promise of uptime. It is a refund policy.
Ignoring the maintenance exclusion. Announced downtime is usually free of charge to the provider.
Assuming credits are automatic. Most require a claim within a stated period.
Promising more than your dependencies allow. You cannot offer 99.99% on infrastructure that is contractually 99.9%.
Confusing SLA with SLO. The internal target you engineer against should be stricter than the number you contract on, leaving room to breach the target without breaching the contract.