Uptime SLA Downtime Calculator

How this is calculated

AN SLA IS A DOWNTIME BUDGET, and converting the percentage into minutes is the only way to reason about it. 99.9% sounds close to perfect until you notice it permits nearly nine hours a year, or about 43 minutes a month - which is one bad deploy. ⚠️ EACH ADDITIONAL NINE DIVIDES THE BUDGET BY TEN, and that is a change of kind rather than degree. Going from 99.9% to 99.99% takes the annual allowance from 8.76 HOURS to 52.6 MINUTES. You cannot get there by being more careful; 52 minutes a year does not survive a single incident where somebody is paged at 3am, wakes up, connects and starts diagnosing - the response alone can spend the entire annual budget. Every nine past the third is an architecture decision about automatic failover, not an operations decision about trying harder. THE MONTH IS THE PERIOD THAT USUALLY MATTERS, because most commercial SLAs are measured and credited monthly. A year of good months does not offset one bad one, and an outage on the last day of the month is a different commercial event from the same outage a day later. A MONTH HERE IS 30 DAYS AND A YEAR IS 365. Real months vary and a leap year adds a day, so treat these as the conventional figures rather than exact ones for your specific calendar - the difference is a couple of percent and it never changes a decision. ⚠️ SLA CREDITS ARE NOT COMPENSATION. When a provider misses its target the remedy is almost always a percentage refund of what you paid them, not payment for what the outage cost you. If an hour offline costs your business far more than an hour of hosting fees - which it usually does - the SLA is a statement of intent and a refund policy, not insurance. Read what the remedy actually is before treating a number as protection. WHAT COUNTS AS DOWNTIME IS DEFINED BY THE CONTRACT, NOT BY YOUR USERS. Providers commonly exclude scheduled maintenance windows, problems they attribute to your configuration, and anything outside their own network - and they usually measure from their monitoring rather than yours. A service can miss every internal target you care about while comfortably meeting the SLA as written. Measuring your own availability is the only way to know what your users experienced. PARTIAL OUTAGES ARE THE COMMON CASE AND THE HARDEST TO COUNT. A service that is up but slow, or working for a tenth of users, is rarely a clean binary. Deciding in advance how you will count degraded service is worth more than any figure on this page.

Common questions

What does 99.9% uptime actually allow?

Nearly nine hours a year, or about 43 minutes in a 30-day month, or roughly 86 seconds a day. Three nines sounds close to perfect and it is a perfectly reasonable target for most services, but 43 minutes is one bad deploy - so it is a budget that a single careless afternoon can spend entirely. Seeing it in minutes rather than as a percentage is the whole point: percentages near 100 all look alike, and the minutes behind them differ by orders of magnitude.

Why is 99.99% so much harder than 99.9%?

Because each additional nine divides the budget by ten, so the annual allowance falls from 8.76 hours to 52.6 minutes. That is not a slightly stricter version of the same problem - it is a different problem. Fifty-two minutes a year does not survive one incident where somebody is paged at three in the morning, wakes up, connects and starts diagnosing; the human response alone can consume the entire annual budget. Anything past three nines has to be handled by automatic failover rather than by people being more careful, which makes it an architecture decision with an architecture budget attached.

Which period should I measure over?

Usually the month, because that is how most commercial SLAs are both measured and credited. It also has a consequence worth understanding: a year of excellent months does not offset one bad one, so an outage on the last day of a month is a different commercial event from the identical outage a day later. If you are sizing an internal reliability target rather than meeting a contract, the year is often the more honest period to reason about, since it stops you gaming a monthly boundary.

Do SLA credits actually cover my losses?

Almost never, and this is the most important thing to understand about them. When a provider misses its target the remedy is typically a percentage refund of your fee for that period - so a service costing a hundred a month might credit you ten or twenty for an outage that cost your business considerably more. An SLA is a statement of intent backed by a refund policy; it is not insurance, and it does not transfer the risk of an outage to the provider in any meaningful way. If downtime genuinely costs you serious money, the answer is redundancy you control, not a better SLA percentage.

Does the provider count downtime the same way I do?

Usually not, and the gap is often large. Contracts commonly exclude scheduled maintenance windows, anything the provider attributes to your own configuration, and problems outside their network - and availability is normally measured from their monitoring rather than from where your users are. That means a service can miss every internal target you care about while comfortably meeting the SLA as written. The only way to know what your users actually experienced is to measure availability yourself, from outside, and treat the provider's figure as a separate commercial number.

How do I count a partial outage?

However you decide in advance, which is the real answer. A service that is up but too slow to use, or working for ninety percent of users, is not a clean binary, and the temptation is always to resolve the ambiguity generously after the fact. Agreeing beforehand what counts - a latency threshold, an error-rate threshold, a proportion of users affected - is worth considerably more than any number this tool produces, because it is the definition rather than the arithmetic that decides whether you met the target.

Is a 30-day month exact?

No, and neither is a 365-day year. Real months run 28 to 31 days and leap years add one, so these are the conventional figures used in nearly every SLA table rather than a calculation for your specific calendar. The difference is a couple of percent, which never changes a decision - if you are close enough to a threshold for the length of February to matter, the problem is not the arithmetic. Some contracts do specify actual calendar days, so it is worth checking which yours uses if a credit is at stake.

Take it further with AI

Copy this into ChatGPT or Claude with your own numbers filled in. It hands over the figures this calculator worked out, so the answer is built on real arithmetic instead of a guess.

I used the Uptime SLA Downtime Calculator at https://www.bfcbrilliance.com/tools/uptime-sla-downtime-calculator.

What I entered:
- Uptime target (%): ___
- Measured over: ___
- Downtime you have actually had (min): ___

What it calculated:
- Downtime allowed in that period: ___
- Budget left: ___
- Share of the budget spent: ___
- Uptime you actually achieved: ___
- Allowed per year: ___

Use those figures as given — they are already worked out, so please don't recalculate or estimate your own. Help me turn them into a plan: what to buy or do, in what order, roughly what it should cost, and the mistakes people most often make with this job.

More running a site tools