Turn Uptime % Into Allowed Downtime

See how many seconds, minutes, or hours you can be offline and still hit your SLA. Also reverse: enter downtime and get the uptime you achieved.

Uptime → Allowed Downtime

Pick a common SLA target, or enter a custom uptime and period.

Inverse: Downtime → Uptime %

You already know how long you were down. What uptime did you achieve?

Allowed Downtime

43.2 min Primary budget

Same budget in other units

Seconds: 2,592 s
Minutes: 43.2 min
Hours: 0.72 h
Period length: 43,200 min

Formula used

allowed_minutes = days × 24 × 60 × (1 − uptime / 100)

30 × 24 × 60 × (1 − 99.9 / 100) = 43.2

Achieved Uptime

99.900% From your downtime input
Downtime used: 43.2 min
Period: 30 days

uptime% = 100 × (1 − downtime_minutes / period_minutes)

What “allowed downtime” means

An SLA (Service Level Agreement) often promises a target like “99.9% uptime.” That number is not magic. It is a budget: how much time the service can be offline and still meet the promise.

Allowed downtime is that budget, written in time (seconds, minutes, or hours). If you stay inside the budget, you meet the uptime target. If you go over, your real uptime drops below the target.

This tool uses one clear formula. It matches the method on our SLA uptime → downtime reference and the same math used in the SLA Penalty Calculator.

Allowed downtime (minutes) = days × 24 × 60 × (1 − uptime / 100)

Achieved uptime (%) = 100 × (1 − downtime_minutes / (days × 24 × 60))

Why teams use this calculator

Managers often hear “three nines” or “four nines” and stop there. Engineers need the time budget. Finance needs the money risk. Allowed downtime is the bridge between the percentage and a real plan.

  • Set on-call and recovery goals that fit the SLA budget.
  • Compare vendors who sell different uptime numbers.
  • Check if last month’s outages still left you inside the contract target.
  • Explain risk to non-technical leaders in plain time units.

Worked examples

Example A — 99.9% over 30 days

Period = 30 × 24 × 60 = 43,200 minutes.

Allowed = 43,200 × (1 − 0.999) = 43,200 × 0.001 = 43.2 minutes.

That is 2,592 seconds, or 0.72 hours. One longer outage can use the whole month’s budget.

Example B — 99.99% over 30 days

Allowed = 43,200 × 0.0001 = 4.32 minutes (about 259 seconds).

Four nines sounds close to three nines. The budget is about 10× smaller.

Example C — Inverse check

You had 60 minutes of downtime in a 30-day month.

Uptime = 100 × (1 − 60 / 43,200) ≈ 99.861%.

That misses a 99.9% promise (budget was only 43.2 minutes).

Example D — Calendar month length matters

Same 99.9% target in a 31-day month: 31 × 24 × 60 = 44,640 minutes.

Allowed = 44,640 × 0.001 = 44.64 minutes — a bit more than the 30-day figure.

Always match the period your contract uses.

Example E — February (28 days) at 99.9%

Period = 28 × 24 × 60 = 40,320 minutes.

Allowed = 40,320 × 0.001 = 40.32 minutes.

That is almost three minutes less than a 30-day model. If your vendor uses calendar months, do not copy a “30-day blog number” into a February credit claim.

Example F — Several short outages add up

You had four incidents of 12 minutes each in a 30-day month → 48 minutes total.

Against a 99.9% budget of 43.2 minutes, you are over by 4.8 minutes.

Achieved uptime = 100 × (1 − 48 / 43,200) ≈ 99.889%. Many teams only remember the “big” outage and forget the small ones. Sum them first, then use the inverse calculator.

Example G — 99.95% over a week

Period = 7 × 24 × 60 = 10,080 minutes.

Allowed = 10,080 × (1 − 0.9995) = 10,080 × 0.0005 = 5.04 minutes.

Weekly budgets are tight. A single bad deploy on Monday can spend the whole week’s allowance. Use weekly views for error budgets; use monthly views when the contract is monthly.

Example H — Year view for planning

99.9% over 365 days: 365 × 24 × 60 = 525,600 minutes.

Allowed = 525,600 × 0.001 = 525.6 minutes (~8.76 hours).

Year numbers help finance and capacity planning. Credit claims still follow the period in your contract (often a calendar month).

Calendar month tip

Many cloud vendors measure availability over the real calendar month (28, 29, 30, or 31 days), not a fixed “30-day slab.”

  • Pick 28 / 29 / 30 / 31 in this calculator to match the month you are reviewing.
  • For leap years, February is 29 days — the budget grows slightly versus a normal February.
  • Keep a small table for your top SLAs, or use our calendar-month SLA downtime tables.
  • When you file a credit claim, quote the same day count the vendor uses. See How to file an SLA service credit claim.

Tip in one line: wrong period length → wrong allowed minutes → weak credit math.

Monitoring tip

Allowed downtime is only useful if you know how long you were actually down. Weak monitoring creates false comfort.

  • Measure from the user’s path. A green CPU graph can hide a broken checkout. Prefer synthetic checks on real URLs.
  • Agree what “down” means. Some contracts need failed health checks from multiple regions. Align your monitors with that definition before you argue about minutes.
  • Log start and end times in UTC. Ambiguous local times cause credit disputes.
  • Separate brownouts from hard downs. Partial degradation may still burn revenue even if uptime “looks fine.” Pair this tool with the downtime cost calculator.
  • Review the month before it closes. If you have already used 35 of 43.2 minutes by day 20, slow risky changes.

Common mistakes

  • Mixing day and month budgets. Daily and monthly numbers are not the same thing. A short daily outage can still burn a monthly budget if it happens often.
  • Ignoring exclusions. Contracts often exclude planned maintenance, customer-caused issues, or third-party networks. Allowed downtime is only the math budget — not always the credit rule.
  • Treating 99.9 and 99.99 as “almost the same.” One more nine cuts the downtime budget by about 10×. Cost and engineering effort rise fast.
  • Using 30 days when the SLA uses calendar months. February and 31-day months change the minutes. Use the period your provider defines.
  • Confusing uptime with user happiness. You can meet the SLA and still hurt customers if outages hit peak sales hours. Pair this tool with the downtime cost calculator.

How this fits with money and penalties

Allowed downtime answers “how much time can we lose?” It does not answer “how much money do we lose?” or “what credit do we owe?”

For money impact of an outage, use Website Downtime Cost. For contract credits when you miss a target, use SLA Penalty Calculator. To compare the cost of buying a higher “nine,” use Cost of Extra Nines.

Quick mental map of common nines

Over a standard 30-day month (43,200 minutes):

  • 99% → 7.2 hours allowed
  • 99.5% → 3.6 hours allowed
  • 99.9% → 43.2 minutes allowed
  • 99.95% → 21.6 minutes allowed
  • 99.99% → 4.32 minutes allowed
  • 99.999% → 0.432 minutes (about 26 seconds)

Full day / week / month / year tables live on the reference guide. This page is the interactive version of that same formula.

Limits (honest notes)

These are estimates for planning. Real contracts define “unavailable” in their own words (health checks, region scope, multi-AZ rules, and more). Numbers here do not replace legal review. They help you ask better questions.

Calculations run in your browser. We do not store the values you type. See our Privacy Policy for details.

Useful next steps

SLA uptime → downtime reference · SLA Penalty Calculator · Cost of Extra Nines · Downtime Cost Calculator

Frequently Asked Questions

What is allowed downtime?
Allowed downtime is how much time a service can be offline and still meet an uptime target. Formula: days × 24 × 60 × (1 − uptime/100).
How much downtime does 99.9% allow in 30 days?
43.2 minutes. That is 43,200 × 0.001 = 43.2 minutes (2,592 seconds, or 0.72 hours).
How do I get uptime % from downtime minutes?
Uptime% = 100 × (1 − downtime_minutes / (days × 24 × 60)). Example: 60 minutes down in 30 days ≈ 99.861% uptime.
Is a month always 30 days?
No. Many cloud SLAs use the real calendar month (28–31 days). Pick the period that matches your contract.
Do small outages count toward the budget?
Usually yes, if they meet the contract’s definition of unavailability. Add every qualifying incident in the period, then compare the total to allowed downtime.
Should I use daily or monthly budgets for on-call?
Use the contract period for credits. Use shorter windows (day/week) as internal error budgets so one bad day does not surprise you at month end.
What if monitoring missed part of an outage?
Your credit case gets weaker. Improve external checks and keep UTC timestamps. Guessing minutes after the fact is hard to defend.
Does meeting allowed downtime mean customers were happy?
Not always. Outages in peak sales hours can hurt more than the same minutes at 3 a.m. Use downtime cost tools for business impact.