NimbusNexus
Free utility · Runs in your browser

An SLA calculator that turns "five nines" into real minutes.

Type a target availability — 99.9, 99.95, four nines, whatever — and see exactly how much downtime you are allowed per day, week, month, quarter, and year. Useful for SLA reviews, incident post-mortems, and reality-checking marketing claims.

Enter a number between 0 and 100. Use up to four decimal places — 99.9999 is meaningful, 99.99999 is below realistic measurement precision.

Common presets
Year length
Allowed downtime
WindowMax downtime
Per day43.2 s
Per week5m 2s
Per month (30d)21m 36s
Per quarter (90d)1h 5m
Per year4h 23m
PRIVACY

Pure arithmetic in this browser tab. No input is logged, no data leaves the page. We never see anything you type.

What you get

Every window in one table, with the precision SLOs need.

A calculator that resolves the abstract "99.95%" into concrete minutes per window, picks sensible units automatically, and lets you swap presets without retyping.

All five windows at once

Day, week, month, quarter, and year — every common SLA reporting window rendered side by side. Compare "9 hours per quarter" against "26 minutes per week" without context-switching.

Sensible auto-units

Below 60 seconds, output is in seconds. Below 60 minutes, in minutes. Above an hour, hours and minutes. Above a day, days and hours. No "0.000732 hours" anywhere.

Six common presets

Two nines through five nines, plus 99.95% (the cloud-vendor sweet spot). One-click apply — useful for "what does AWS S3 actually promise" or comparing a vendor SLA against your internal SLO.

Leap-year toggle

Year length defaults to 365 days; switch to 366 for leap years. Adds about 4 minutes of allowed downtime per year at 99.999% — small, but visible in five-nines budgeting.

Per-row copy

Click any row to copy "Per quarter: 1h 5m 24s" — handy when filling out post-mortem templates or SLO dashboards.

Live recalculation

Every keystroke or preset click rebuilds the table. No Calculate button.

High precision

Inputs accept up to four decimal places (99.9999 is meaningful). Past that, the difference is below what is measurable in real systems with discrete probes.

No sign-up, no logging

Use anonymously. No account, no history, no telemetry. Inspect the network tab and watch nothing happen.

Common uses

Wherever an SLA has to be made concrete.

INCIDENT
Frame a post-mortem

"43 minutes of downtime sounds bad — was it?" Convert your SLA to per-quarter minutes, compare. If you burned 80% of the quarterly budget, that needs a different post-mortem than 5%.

99.95% SLA → 21m 36s/month → 43m = 2× monthly budget
VENDOR
Compare cloud SLAs

AWS S3 promises 99.9% (legal), 99.99% (typical). Translate both into actual outage minutes you can plan around — and stack them against each other and against your customer-facing promise.

S3 99.9% → 8h 45m/year of allowed outage
SLO
Set an internal SLO

You promise customers 99.9%. Internal SLO usually targets one nine higher — 99.99% — leaving headroom for unknowns. Calculator shows what 99.99% means in real minutes per release cycle.

99.99% → 4m 21s/month error budget
REVIEW
Quarterly SLA review

Pull the actual incident minutes for the quarter, compare against the quarterly budget. If you have headroom, ship faster. If you blew through it, slow down and harden.

Q1: 99.978% measured · 99.99% target → over budget
CONTRACT
Decode a vendor contract

"Service Credit Tier 3: <99.0%". Convert 99.0% → ~7h 18m per month of allowed outage before you get a credit. Use to score whether a vendor SLA is worth the upcharge.

<99% per month → 50% credit
MARKETING
Sanity-check a "five nines" claim

Five nines = 5m 15s of downtime per year. Enterprise SaaS that claims it usually means "before excluded maintenance windows" — read the fine print. The number alone is rarely as good as it sounds.

99.999% → 5m 15s/year
FAQ

SLAs and SLOs, the plain answers.

How is allowed downtime calculated?

Linearly: `downtime = window × (1 - availability)`. For 99.95% per quarter (90 days): 90 × 24 × 60 × 60 × 0.0005 = 3,888 seconds = 1h 4m 48s. The math is straightforward; the value is in having every window rendered at once.

Why do month and quarter use 30 and 90 days?

Standardized for budgeting purposes. Real months vary 28–31 days; using 30 keeps month-to-month budgets comparable. Same for quarter (90 days). For an actual calendar month or quarter, scale linearly — a 31-day month gives 3.3% more downtime than the 30-day budget.

What is the difference between SLA and SLO?

SLA = the legal promise to your customers, with consequences for violation (service credits, etc.). SLO = the internal target the team operates against, usually one nine stricter than the SLA — leaving a buffer for unknowns. Both use the same arithmetic; the calculator does not care which one you are computing.

Should I trust a "five nines" SLA from a vendor?

Read what is measured. Most enterprise SLAs exclude planned maintenance windows, third-party outages, and "force majeure." A 99.999% SLA with 4 hours of monthly excluded maintenance is closer to 99.5% in practice. Calculate both — the bare SLA and the as-experienced — to see the gap.

Will my data be sent to a server?

No. The whole calculator is ~50 lines of arithmetic in this browser tab. The page makes no network calls. Open DevTools → Network and watch nothing happen.

Why not include "rolling 30 days" or other windows?

Most contracts use the calendar windows we already show (day / week / month / quarter / year). A rolling-window SLO is a measurement choice — you can compute its allowed downtime by treating the window as 30 days (= the existing month row). If you want a custom window picker, drop us a note via /contact.

When you need more

Building services that need to hit those numbers?

Sign up for the free tier and you get $100 in credits, plus VMs across four regions, automated failover for managed databases, snapshots, and load balancing.