Uptime SLA Calculator — Allowed Downtime Per Day, Week, Month and Year

Background.

An availability target is a percentage, and a percentage is impossible to reason about until you convert it into minutes. This calculator does that conversion in both directions: it turns any target — 99%, 99.9%, 99.95%, 99.99%, five nines, anything in between — into the downtime it permits per day, per week, per month and per year, and it turns downtime you have already had into the availability figure that represents and the error budget it leaves you.

The headline numbers are smaller than most people expect. Three nines, 99.9%, sounds generous until you see that it is 43.2 minutes a month on a 30-day month, and 8.76 hours across a year. Four nines is 4.32 minutes a month — one bad deployment. Five nines is 25.92 seconds a month, which is less time than it takes most clusters to notice a node has failed, let alone route around it. Going from three nines to four does not make a service ten percent better; it cuts the permitted failure window by a factor of ten, and every order of magnitude costs disproportionately more than the last.

Month length is an input here rather than a hidden constant, because it changes the answer materially and because real SLAs measure over calendar months or billing cycles. February at 28 days grants 40.32 minutes at 99.9%; July at 31 days grants 44.64. That is a 10.7% difference in your budget from nothing but the calendar, and it is the reason published "nines tables" all quietly pick 30 days and move on. The default here is 30 so that the outputs reproduce the widely cited tables exactly, but the other options are one click away and the annual figure has a leap-year option for the same reason. The underlying time constants are the SI-accepted ones — a minute is 60 seconds, an hour is 3,600, a day is 86,400 — not conventions this page invented.

The error budget outputs come from the other side of the same identity. If the objective is 99.9%, the budget is the remaining 0.1%, and Google's SRE Workbook states the relationship in exactly those terms: the error budget is 100% minus the SLO. Expressed in minutes of a month, that budget is a concrete, spendable quantity. Enter the downtime you have already taken and the page tells you how many minutes are left, what proportion you have burned, and what availability you are currently running at. That last figure matters because the SLA is assessed on the whole measurement period, not on the incident: twelve minutes of downtime in a 30-day month is 99.972% availability, comfortably inside a three-nines commitment even though the outage itself felt like a disaster.

One scope limitation stated plainly, because getting it wrong makes the answer meaningless. This is a time-based availability model — downtime minutes over period minutes. Not every SLA works that way. Amazon EC2's Monthly Uptime Percentage is time-based, defined as 100% minus the percentage of minutes in the month during which the service was unavailable, and this calculator matches it directly. Amazon S3's is not: it is defined by averaging the error rate across every 5-minute interval in the billing cycle, so a service that answers 99% of requests continuously registers as 99% available even though it was never fully "down". If your SLA is request-ratio based, the arithmetic on this page still applies — substitute failed requests for downtime minutes and total requests for the minutes in the month — but the labels will not match your contract. Read the definition clause before you argue about a credit.

Below the widget: the full derivation, a worked example checked line by line against Google's published Table of Nines, guidance on what each nine actually costs to operate, the difference between an SLA, an SLO and an SLI, and why a service that meets its SLA every month can still be one your customers describe as unreliable.

What is uptime sla calculator?

Availability is the proportion of a measurement period during which a service was usable. Google's SRE book gives the time-based form directly: availability equals uptime divided by uptime plus downtime. Because the two terms sum to the period, the complement is easier to work with — if a target is 99.9%, then 0.1% of the period may be spent unavailable, and multiplying that fraction by the length of the period gives the downtime budget in real units. That budget is what an SLA is actually enforceable on. A Service Level Agreement is the contract: a commitment, a measurement definition, and a remedy, usually a service credit expressed as a percentage of the bill. A Service Level Objective is the internal target a team runs to, normally set tighter than the contractual SLA so there is room to react before money is at stake. A Service Level Indicator is the measurement itself — the thing you actually instrument. The error budget is the SLO's complement: 100% minus the objective, expressed as a spendable quantity of failure. Teams use it as a control mechanism rather than a scorecard, releasing freely while budget remains and freezing risky changes once it is gone. The critical detail in every one of these documents is the measurement definition, not the number. Two providers can both advertise 99.9% and mean entirely different things by it — one measuring minutes of total unavailability, the other averaging request error rates over five-minute intervals — and the second is considerably harder to breach.

How to use this calculator.

1. 01Enter your availability target as a percentage: 99.9 for three nines, 99.99 for four. Do not enter it as a decimal fraction — 0.999 would be read as a target of roughly zero-point-nine-nine-nine percent, which allows almost the whole month.
2. 02Pick the month length your SLA is measured over. Most contracts say calendar month or billing cycle, so use the actual month you are in. Leave it at 30 days if you want the figures that published availability tables quote.
3. 03Set the year length. Use 366 in a leap year — it adds 24 hours of exposure, worth 1.44 extra minutes of budget at 99.9%.
4. 04Enter the downtime you have already recorded this month, in minutes. Leave it at 0 to read the allowance table on its own.
5. 05Read the monthly allowance first — that is the number credits are assessed against — then the remaining budget and the percentage consumed, which tell you how much risk you can still afford this month.
6. 06Check the achieved availability figure against your target. Availability is assessed across the whole period, so a long outage early in a long month can still land inside the commitment.

The formula.

The whole page rests on one identity: over a fixed period, the time a service may be unavailable is the period multiplied by one minus the availability target. Everything else is a unit conversion.

Start by converting the target to a fraction and taking its complement. A target of 99.9% is 0.999, so the unavailability fraction is 0.001. This complement is what the SRE literature calls the error budget, and the Google SRE Workbook states the relationship as plainly as it can be stated: the error budget is 100% minus the SLO.

Now multiply that fraction by each period, expressed in whatever unit makes the answer readable. A day is 86,400 seconds, so 0.001 × 86,400 = 86.4 seconds. A week is 7 × 1,440 = 10,080 minutes, so 0.001 × 10,080 = 10.08 minutes. A 30-day month is 43,200 minutes, so the allowance is 43.2 minutes. A 365-day year is 8,760 hours, so the allowance is 8.76 hours. These are not approximations — they are exact, and they match Google's published Table of Nines row for row.

The reverse direction is the same identity rearranged. Divide observed downtime by the minutes in the month to get the unavailability fraction actually incurred, subtract from one, and multiply by a hundred. Twelve minutes in a 43,200-minute month is 12 ÷ 43,200 = 1/3,600 of the period, which is 0.0277…%, so achieved availability is 99.9722…%.

The error budget position is then two subtractions. Remaining budget is the monthly allowance minus observed downtime, and it is deliberately allowed to go negative so the size of a miss is visible rather than clamped to zero. Budget consumed is observed downtime divided by the allowance, times a hundred, and is deliberately allowed to exceed 100% for the same reason.

One case needs defining rather than dividing. At a target of exactly 100%, the monthly allowance is exactly zero, and dividing by it would produce Infinity or NaN. This calculator defines the consumed figure at a 100% target as 0% when there has been no downtime and 100% — budget fully consumed — when there has been any downtime at all. The remaining-minutes output carries the real magnitude, going straight to minus the observed downtime.

A note on what the arithmetic cannot capture. Availability computed this way is a duration ratio and treats all minutes as equal. Ninety seconds of downtime at 03:00 on a Sunday and ninety seconds at 11:00 on the last business day of the quarter produce an identical figure and radically different consequences. It also says nothing about how the downtime was distributed: one 43-minute outage and forty-three one-minute outages both spend exactly the same three-nines monthly budget, and users experience them completely differently. Serious reliability programmes therefore track outage frequency and duration distribution alongside the headline percentage, not instead of it.

A worked example.

Frequently asked questions.

References& sources.

1. [1]Beyer, Jones, Petoff & Murphy (eds.), Site Reliability Engineering (Google / O'Reilly), chapter 'Embracing Risk'. Source of the time-based definition used here — 'Availability = Uptime / (Uptime + Downtime)' — and of the statement that 'a system with an availability target of 99.99% can be down for up to 52.56 minutes in a year', which independently confirms the 365-day year basis this calculator uses.
2. [2]Site Reliability Engineering, Appendix: Availability Table ('Table of Nines'). The published allowance rows this calculator reproduces exactly on a 30-day month and 365-day year: 99.9% → 8.76 h/year, 43.2 min/month, 10.1 min/week, 1.44 min/day; 99.99% → 52.6 min/year, 4.32 min/month; 99.999% → 5.26 min/year, 25.9 s/month.
3. [3]The Site Reliability Workbook (Google / O'Reilly), chapter 'Implementing SLOs'. Source of the error-budget definition used on this page: 'the error budget is 100% minus the SLO', illustrated with a 99.9% success-ratio SLO over 3 million requests permitting 3,000 errors in four weeks.
4. [4]Amazon Web Services, Amazon Compute Service Level Agreement. Source of the time-based measurement definition this calculator implements — 'Monthly Uptime Percentage is calculated by subtracting from 100% the percentage of minutes during the month in which Amazon EC2 was in the state of Unavailability' — and of the Region-level service credit tiers: 10% below 99.99%, 30% below 99.0%, 100% below 95.0%.
5. [5]Amazon Web Services, Amazon S3 Service Level Agreement. Cited as the contrasting, request-ratio measurement style: a 99.9% Monthly Uptime Percentage commitment 'calculated by subtracting from 100% the average of the Error Rates from each 5-minute interval in the monthly billing cycle', with credits of 10% below 99.9%, 25% below 99.0% and 100% below 95.0%.
6. [6]NIST Special Publication 330, section 4, Table 8 — non-SI units accepted for use with the SI. Source of every time constant in this calculator: 1 min = 60 s, 1 h = 60 min = 3600 s, 1 d = 24 h = 86 400 s.