SLA Uptime Calculator

The vendor's slide says 99.9% uptime, guaranteed. The room nods. Somebody in procurement writes it down as though it were a quality, like 'sturdy' or 'reliable,' and the meeting moves on. What nobody does is multiply — because 99.9% is not a quality, it is a quantity of broken, and the quantity is forty-three minutes and fifty seconds of dead service every month. If the service in question is your checkout, and the month is December, you have just approved a contract whose fine print allows Black Friday to go dark during the peak sale hour, twice.

This is the persistent trick of SLA mathematics: the percentages are chosen to sound adjacent to perfection while encoding an amount of downtime you would never accept if it were read aloud. One nine is three and a half days of outage a year. Two nines is under four hours — no, wait: two nines is 3 days 15 hours 39 minutes 30 seconds, which is to say, still a long weekend of failure with no service at all. The gaps between the nines are where entire engineering philosophies live, and the only way to see them is to run the arithmetic.

So: a calculator that turns percentages into minutes. Type an availability target and get downtime per day, week, month and year; browse the full two-to-six nines table; see the error-budget math that operations teams use to decide when reliability work outranks feature work; and copy an SLA clause template with the exclusions written in plain language. The tool is above; the number theory is below; both take about four minutes, which is 0.0000023 of your year.

The main input is an availability percentage — 99.9, 99.95, three nines or six — and the output is a table of allowed downtime across five reporting windows: per day, per week, per month, per quarter, and per year. The windows matter because SLAs are measured in one of them, usually the calendar month, and the same percentage means wildly different incident budgets depending on the window the lawyers chose. A 99.9% quarterly SLA gives you two hours eleven minutes to spend per quarter; the monthly version gives forty-three minutes and fifty seconds; same nines, different leash.

The second direction converts an outage you already suffered into the availability it left behind: type '2 hours 15 minutes in a 31-day month' and learn that you finished at 99.697% — below three nines, worth a credit claim, worth a postmortem. The third piece is the error-budget view: given a monthly SLA and the outages so far, how much downtime remains before the month breaches. Operations teams run their release schedules on exactly that number, and now it is one field instead of a spreadsheet.

Everything runs locally in the browser, and the numbers follow the uptime.is convention — a mean calendar year of 365.2425 days, the same arithmetic the reference site for this calculation uses. Conventions are the quiet variable in every SLA conversation; the section on edge cases covers what changes when a contract specifies calendar months or rolling windows instead.

The tool answers three questions — how much brokenness does a target allow, what did an outage cost me in nines, and how much budget remains. Each is a separate input on the page above.

1. 1

   Enter the availability target

   Type the percentage from the contract or the proposal — 99.9, 99.95, 99.99. The downtime table re-renders instantly across all five windows.

2. 2

   Pick your reporting window

   Check the contract for the measurement period — monthly is the most common, quarterly appears in enterprise agreements, and annual shows up in internal objectives. The calculator shows all of them so you can compare what the same nines mean per window.

3. 3

   Convert an outage into availability

   Enter the downtime you experienced and the window length; the tool returns the availability percentage and whether it breached a threshold worth claiming.

4. 4

   Check your remaining error budget

   Subtract incidents already spent this month from the total the SLA allows. The remainder is the number your release train should be consulting before every deploy.

5. 5

   Copy the clause template when negotiating

   The template near the end of this page covers measurement window, exclusions, credit tiers and claim deadlines — the four paragraphs that decide whether an SLA has teeth.

The underlying arithmetic could not be friendlier: allowed downtime equals one minus the availability target, times the length of the window. Everything else is unit conversion. A day is 86,400 seconds; a week is 604,800; a month, in the mean-calendar convention this tool uses, is 30.436875 days or 2,629,746 seconds; a quarter is 7,889,238 seconds; and a year is 365.2425 days — 31,556,952 seconds, the average length that calendar years actually average out to once you account for leap years.

That 365.2425 figure is the convention uptime.is uses, and it is the one adopted here for a reason beyond consistency: it is the honest average. A contract that measures calendar months gives you a slightly bigger allowance in a 31-day month than a 30-day one, and a calculator using a flat 365-day year reports 8h 45m 36s for three nines — twenty-one seconds apart, which nobody will litigate, but which is worth knowing when two dashboards disagree.

Here is the ladder everyone in infrastructure has partially memorized and nobody has fully internalized — downtime per year, from a sloppy two nines to the five-nines ceiling. Note how each additional nine divides the previous row by ten, and how quickly 'adjacent to perfection' becomes 'reboot budget.'

The bottom row deserves its reputation and a pinch of skepticism in equal measure. Five nines is roughly five minutes a year — and unplanned incidents are not the only clock running: routine patching, hardware replacement and configuration drift all consume the same budget unless redundancy carries the load. Organizations that genuinely operate at five nines do it with multi-region architectures and automated failover, not with luck and a pager. When a brochure promises it from a single-server product, ask what the architecture is; the number is a design document disguised as a metric.

Most commercial SLAs measure the calendar month, and on-call rotations think in weeks, so here are both tables. The monthly numbers are the ones to bring into contract negotiations; the weekly ones are the ones your incident channel will feel.

The monthly table is where vendor claims meet operational reality. Forty-three minutes and fifty seconds a month at three nines sounds generous until a single DNS incident eats the whole budget before lunch and the quarter's remaining incidents are all, technically, breaches. That is not a vendor failing — it is what the number meant all along, and the reason the next section exists.

Site reliability engineering reframed this whole topic with one idea: the allowed downtime in an SLA is a budget, and every incident spends it. At 99.9% monthly you start each month with 2,629.7 seconds — 43 minutes 50 seconds — of error budget. A five-minute blip on Monday spends 300 seconds of it. When the budget hits zero, the reliable move is to freeze feature releases and spend engineering time on reliability until the window resets, because every additional second is now a contractual breach with your name in the postmortem.

Mature teams alert on the rate of spending, not just the total. The standard burn-rate thresholds from the Google SRE workbook: an alert when you consume 2% of a 30-day budget in one hour — a burn rate of 14.4×, meaning something is badly wrong right now — and a slower alert at 6× burn, catching a leak that would quietly drain the month. This calculator gives you the budget those alerts are measured against, and the Cron Next Run Checker handles the other half of the on-call question: when the maintenance job that might cause the next incident is scheduled to fire.

An uptime percentage is only as honest as its exclusions, and the exclusion list is where contracts earn their keep. Scheduled maintenance announced in advance is typically excluded entirely — which is how a vendor can patch every month at 2 a.m. and still report 100% measured availability. Force majeure, acts of government, and customer-caused outages follow it out the door. None of this is fraud; it is the industry's standard accounting. It just means the percentage describes a narrower slice of time than the brochure implies.

Then there is degradation, the gray zone. If the service is technically responding but slow enough that users abandon it, most SLAs count it as up — unless the agreement defines a performance threshold, which many do not. Measurement is its own asymmetry: the vendor's dashboard usually decides whether an incident happened, and the claim window is often 30 days, after which the credit evaporates. The percentage on the first page of the contract is the headline; these four paragraphs are the article.

The credit structure deserves equal skepticism, because it is designed to feel like accountability while capping exposure. The major clouds publish the pattern openly — Amazon's EC2 SLA commits to 99.99% regionally per month with credits that escalate as availability drops, and Google's Compute Engine SLA runs the same monthly window with a similar ladder. The ladder typically tops out at 30% of the month's bill. Your outage cost is revenue and reputation; the remedy on offer is a discount on the service that failed. Negotiate the clause accordingly, or at least read it with both eyes open.

When you are the one writing the requirements — an internal team's service objective, or a procurement document a vendor must sign — the structure below covers the four load-bearing elements: the measurement window, the exclusions, the credit ladder, and the claim process. Adapt the numbers to what the chmod Calculator-verified, properly-permissioned infrastructure you are actually running can deliver, not to what sounds impressive in a review meeting.

Availability Commitment
  The Service will achieve at least 99.95% availability in each
calendar month, measured as (total minutes - Downtime) / total minutes.

Exclusions
  Downtime excludes Scheduled Maintenance announced >= 72 hours in
advance via status page and email, and Force Majeure Events. Degraded
performance (response times exceeding 2x the 30-day median) counts as
Downtime when it persists for 10 consecutive minutes.

Service Credits
  99.0% to 99.95% measured: 10% of monthly fees
  98.0% to 99.0% measured: 25% of monthly fees
  below 98.0% measured:     50% of monthly fees

Claims
  Customer must report a breach within 30 days of month end; unclaimed
credits expire. Credits apply to future invoices and are not the sole
remedy for repeated failure (three consecutive breached months permit
termination without penalty).

The termination-for-chronic-breach clause is the one vendors resist and the one that matters most. Credits compensate incidents; exit rights compensate for a partner whose reliability trajectory no longer matches yours.

• Calendar month versus mean month: contracts usually measure calendar months, so January's budget is about 44,640 seconds and February's about 41,760 — the calculator's 2,629,746-second month is the fair average
• Rolling windows: some vendors measure the trailing 30 days at all times, which smooths a single bad night but also lets a breach slide out of scope while you are still angry about it
• Excluded time drifts into the denominator disputes: whether maintenance minutes appear in 'total minutes' changes the arithmetic more than any convention of year length
• Partial availability: a system serving 60% of requests successfully can be argued as 60% available for the window rather than fully down — insist on weighted or fully-down accounting
• Measurement authority: if only the vendor's dashboard counts, your monitoring disagreement has no legal standing; require shared telemetry or third-party measurement for high-stakes contracts

None of these edge cases change the nines table; they change which nines you were actually promised. Running the percentage through this calculator tells you what the number means in minutes. Reading the contract's definitions tells you which minutes were ever on the table. You need both, in that order, before the meeting where everyone nods.

Operations and SRE teams are the daily users — translating objectives into budgets, checking whether a fast-burning incident warrants paging leadership, and sanity-checking the vendor dashboards that report suspiciously smooth months. Engineering managers use it in the other direction: turning 'we lost eleven minutes last night' into the availability figure an executive summary can carry. Procurement and vendor-management teams use it before renewal negotiations, because a credit conversation goes differently when both sides can see that 99.9% was thirty-one dollars of credit and forty thousand of lost orders.

The third crowd is anyone on the buying side of a cloud, SaaS, or managed-service contract — which is to say, nearly every business with an internet-shaped dependency. A percentage is a marketing artifact until it is converted into minutes; after conversion it is a risk statement, and risk statements are what procurement was invented to read. The same drawer of deployment arithmetic that holds this page also holds the Cron Next Run Checker for schedule verification and the wider code tools shelf for the rest of the pre-launch checklist.

The next time a slide says four nines, you will hear fifty-two minutes and thirty-six seconds of silence per year, and you will know what the architecture must look like for that to be true. For the numbers that come after the SLA is signed — what the deployment scripts may do, when the maintenance jobs fire — the chmod Calculator and Cron Next Run Checker are the rest of the checklist.