SLA Uptime → Downtime Reference (and How Our Calculators Work)

1. Core formula

Example: 99.95% over a 30-day month → 43,200 × 0.0005 = 21.6 minutes of allowed downtime.

Uptime achieved from measured downtime:

These two formulas are enough for most planning work. First you find the budget (allowed downtime). Then you compare it to what monitoring measured. If measured downtime is larger than the budget, your achieved uptime is below the SLA target.

2. Quick lookup

Pick an SLA and period. Values use the same formula as the tables below and our SLA calculator.

3. Full reference tables

Values are exact from the formula above. Display units switch to seconds, minutes, or hours for readability. Cloud contracts often use calendar months (28–31 days); the 30-day column is the industry comparison baseline. For every calendar month length in one view, see calendar-month SLA downtime tables.

Allowed downtime by SLA (human-readable)

Same data in minutes (for spreadsheets & models)

4. Leap years note

A normal year has 365 days = 365 × 1,440 = 525,600 minutes. A leap year has 366 days = 366 × 1,440 = 527,040 minutes. The difference is 1,440 minutes — one extra day.

Our yearly column uses 365 days because that is the common comparison baseline in blogs, decks, and vendor marketing. It is not always the length your contract uses for a full calendar year.

• If your SLA measures a calendar year that includes February 29, use 366 days (or ask your vendor how they count).
• If your SLA measures each calendar month, leap day only changes February (28 → 29 days). Other months stay the same.
• The percentage math does not change. Only the period length changes.

Leap seconds are ignored on this site. They are tiny for SLA planning and almost never appear in cloud credit math.

5. 99.999% (“five nines”) reality check

99.999% sounds like a small step up from 99.99%. In practice it is a different world. Over a 30-day month you get only 0.432 minutes of allowed downtime — about 26 seconds.

That is less time than many teams need to confirm an alert, open a bridge call, and decide what to do. A single failed deploy, a DNS blip, or a short regional issue can burn the whole monthly budget.

• 99.9% (three nines): ~43.2 minutes / 30 days — still tight, but some planned work can fit if the contract allows it.
• 99.99% (four nines): ~4.32 minutes / 30 days — one short outage can use most of the budget.
• 99.999% (five nines): ~26 seconds / 30 days — almost no room for any customer-visible failure.

Five nines usually requires multi-region design, fast failover, careful change control, and clear definitions of what counts as “down.” Buying a higher SLA number without changing architecture rarely delivers five-nines outcomes. Use the tables to set expectations with leadership: the time budget is the real message, not the marketing label.

Also remember: the SLA budget is not the same as a credit payout. You can miss five nines and still receive only a small credit if the vendor’s tier table caps it. See our guide on how to file a service credit claim and the SLA Penalty Calculator.

6. Common cloud month confusion

People mix three different “months” when they talk about SLA math. Keep them separate:

1. Fixed 30-day month — useful for comparison and textbooks. Period = 43,200 minutes. Easy to remember.
2. Calendar month — what many cloud SLAs actually use: 28, 29, 30, or 31 days. Budget changes with the month.
3. Billing month — sometimes aligned with invoice dates, which may not start on the 1st. Read your contract.

A frequent mistake: take a 30-day table value and apply it to March (31 days) or February (28/29 days). For 99.9%, February (28 days) allows 40.32 minutes, while a 31-day month allows 44.64 minutes. That is more than four minutes of difference — enough to change whether you are over or under the budget after a short outage.

Another frequent mistake: comparing “monthly uptime” from a monitoring tool that uses a rolling 30 days with a vendor SLA that uses a calendar month. Align the window before you argue about credits.

Tip: when you file a claim, write the period in full: “Calendar month March 2026 (31 days = 44,640 minutes).” Clear period language reduces back-and-forth with support.

7. Spreadsheet copy tips

You can rebuild every cell on this page in Excel, Google Sheets, or LibreOffice. Use one formula and change the inputs.

• Put days in one cell and uptime in another. Reference those cells so you can switch from 30 to 31 days without rewriting math.
• Store uptime as 99.95 (percent) or as 0.9995 (fraction) — but do not mix styles in one sheet.
• For display, keep full precision in the calculation cell, then format to 2–4 decimal places for reading.
• When pasting our minutes table, paste as values first, then add a “source” note with this page URL and date.
• To convert minutes to hours: divide by 60. To convert to seconds: multiply by 60.

If your sheet disagrees with our table by a tiny amount, check floating-point rounding. Values like 4.32 and 21.6 are exact for the common percentages above when you use decimal arithmetic as shown.

8. How to cite this page

You may cite these tables and formulas in tickets, runbooks, academic work, and internal reports. Please link the canonical URL and state your inputs so others can reproduce the number.

• Always include the uptime % and period length you used.
• If your claim uses a calendar month, say 28/29/30/31 — do not only say “a month.”
• Save a screenshot or PDF if you need a fixed evidence pack for a vendor claim.
• This page is a methodology reference. It is not legal advice and not your vendor’s SLA text.

9. SLA credit methodology (open)

Our SLA Penalty Calculator estimates service-credit exposure. It does not replace your vendor’s SLA text.

Steps

1. Compute actual uptime from downtime minutes (or take achieved uptime as input).
2. Compute shortfall = max(0, promised_uptime − actual_uptime), in percentage points.
3. If shortfall = 0 → penalty = 0.
4. Else map shortfall into an editable penalty tier (threshold → % of contract value).
5. Estimated credit = contract_value × (tier_percent / 100).

Worked example: $1,000,000 contract, 99.95% promised, 99.72% actual → shortfall 0.23 pp. If that lands in a 10% tier → estimated credit = $100,000.

For a practical claim checklist (logs, exclusions, deadlines, evidence pack), read How to file an SLA service credit claim.

10. Downtime cost methodology (open)

The Website Downtime Cost Calculator estimates business impact of an outage window—not contractual credits.

Use your own revenue/hour and staffing numbers. Published “$X per minute” industry averages are context only—they are not universal constants.

11. RTO / RPO impact methodology (open)

The RTO/RPO Impact Calculator annualizes recovery and data-loss exposure.

RTO (Recovery Time Objective) is how long systems may stay down. RPO (Recovery Point Objective) is how much data you can afford to lose, expressed as time since the last good recovery point.

12. Assumptions & limits

• Time math uses 24-hour days. Leap seconds are ignored.
• Reference tables use fixed period lengths (1 / 7 / 30 / 365). Real SLAs may use calendar months.
• Yearly comparison uses 365 days unless you explicitly switch to 366 for a leap year.
• “Unavailable” is defined by each contract (probe failures, partial degradation, maintenance windows, etc.).
• Credits are usually future invoice reductions, not cash refunds, and often require timely claims with evidence.
• All TechImpact outputs are estimates for planning and negotiation support—not legal or accounting advice.
• Calculations run in your browser; we do not store your contract inputs on a server.

13. FAQ