SLA Math — What 99.9% Uptime Really Costs You in Downtime Hours

Picture this: you’re on a call with a client, they ask for “99.99% uptime,” you say sure, and you both move on. Six months later you’re staring at an SLA credit clause wondering how you got here. That guarantee you casually agreed to allows exactly 52 minutes of downtime per year — and most of that will disappear in a single bad deploy.

This is the math every developer should have in their head before signing an SLA or committing to an uptime number in a proposal.

The Formula

Availability percentages convert to downtime using one simple formula:

Downtime = (1 – availability) x period

For 99.9% uptime: 1 – 0.999 = 0.001. Multiply by the minutes in a year (525,960) and you get 525.96 minutes — or 8.77 hours of allowed downtime annually. That’s not a catastrophic outage. That’s a rough Tuesday afternoon deploy that spirals for a few hours, a database failover that takes longer than expected, and a midnight dependency update that breaks the auth service. Eight hours goes fast.

The Reference Table

Bookmark this. Every number here is calculated the same way — (1 – availability) x period length in minutes, then converted to the most readable unit.

Availability	Downtime/Day	Downtime/Week	Downtime/Month	Downtime/Year
99%	14.4 min	1.68 hr	7.3 hr	87.6 hr
99.5%	7.2 min	50.4 min	3.65 hr	43.8 hr
99.9%	1.44 min	10.08 min	43.83 min	8.77 hr
99.95%	43.2 sec	5.04 min	21.92 min	4.38 hr
99.99%	8.64 sec	1.01 min	4.38 min	52.6 min
99.999% (five nines)	0.864 sec	6.05 sec	26.3 sec	5.26 min

Read the 99.999% row again. Five minutes and twenty-six seconds of allowed downtime per year. Total. Including planned maintenance, failed health checks, and the 30 seconds your load balancer takes to notice a dead node. You can do the math on how realistic that is for most teams.

What Five Nines Actually Requires

Five nines (99.999%) is not just “good infrastructure.” It’s a different engineering discipline. To get there you need:

• Full redundancy at every layer — no single points of failure anywhere in the stack, including DNS, CDN, database, and application tier
• Automated failover with sub-second detection — humans cannot respond fast enough; your monitoring and failover need to run without intervention
• Zero-downtime deployments — blue/green or canary, with automated rollback. Any deploy that requires a restart eats into your 5-minute budget
• Multi-region active-active setups — a single region going down cannot take you with it
• Planned maintenance outside SLA windows — most 99.9% SLAs explicitly exclude scheduled maintenance, but 99.999% SLAs often do not have room for it

The companies actually hitting 99.999% — AWS S3, Google Cloud Storage — have dedicated reliability engineering teams, years of chaos engineering data, and infrastructure spend that would make most SaaS founders faint. It is achievable, but not by accident and not cheaply.

You can use the Uptime / SLA Calculator to run these conversions for any availability percentage and any time window you’re working with.

The SLA Credit Problem

Here’s the part that catches people off guard: SLA credits from cloud providers do not compensate you for your actual losses. They compensate you for a fraction of your hosting bill.

AWS, GCP, and Azure typically offer 10–30% of your monthly service bill as a credit when they breach their SLA. If you’re paying $500/month for EC2 and they have a 2-hour outage that violates the SLA, you might get a $50–150 credit. Meanwhile you have potentially lost thousands in revenue, burned engineer-hours on incident response, and damaged client trust.

When you’re writing SLAs with your own clients, understand that this is the standard model — credits are goodwill gestures tied to service fees, not full indemnification. Read the remedies clause carefully. Many enterprise clients will try to negotiate actual damages language; that’s a different conversation that involves lawyers, not SREs.

Monthly vs. Yearly Windows Matter

SLAs are measured over a specific window, and that window matters more than most people realize. A yearly 99.9% SLA gives you 8.77 hours of total downtime spread across 12 months. A monthly 99.9% SLA gives you only 43.83 minutes per month — but that resets every month.

Clients almost always want monthly measurement — it sounds stricter, and it gives them leverage if you have one bad month. What they do not always realize is that monthly measurement can actually give you less total slack: 43.83 minutes x 12 months = 525.96 minutes per year, which is exactly the same as the yearly calculation. The difference is that with monthly SLAs, a single rough month can trigger a breach even if the rest of the year was perfect.

When negotiating, push for yearly measurement windows where possible. When clients insist on monthly, make sure your infrastructure can actually hit 99.9% any given month — not just on average across the year.

What to Actually Promise

Here’s the guidance that’s actually useful:

Personal projects and early-stage products

99% is honest and fine. Nine hours of downtime per month is realistic for a small team without dedicated ops. Do not promise more than you can consistently deliver — the reputational cost of missed SLAs is worse than setting lower expectations upfront.

B2B SaaS on standard cloud infrastructure

99.9% is the right target. With proper monitoring, auto-scaling, managed databases, and a CI/CD pipeline that does not require downtime to deploy, this is genuinely achievable on AWS, GCP, or Azure without heroic effort. The 43-minute monthly budget is tight but workable if you have deployment automation sorted.

99.99% and beyond

This requires real investment: load balancers across multiple availability zones, multi-region failover, database replication with automatic promotion, and someone who owns reliability as their primary job. If a client is asking for 99.99% and you do not have that infrastructure in place yet, the honest answer is to negotiate to 99.9% and build toward 99.99% as a roadmap item — with the corresponding infrastructure cost increase reflected in pricing.

99.999% is Amazon and Google territory. Unless you’re operating financial infrastructure, healthcare systems, or telecom-grade services with a dedicated SRE team, this is not a realistic commitment.

Run the Numbers for Your Situation

The math here scales to any time window and any availability target. If you’re working with a non-standard SLA period — a 90-day rolling window, a fiscal quarter, a custom measurement period — the formula stays the same: multiply the downtime percentage by the number of minutes in your window.

The Uptime / SLA Calculator on IO Tools handles all of this — plug in any availability percentage and time period to get the exact downtime allowance, which is useful when drafting SLA language or responding to a client’s uptime requirement with a realistic counterproposal.

The summary: 99.9% is the practical ceiling for most teams without dedicated reliability investment. Anything above that costs real money and requires real process changes. Know what you’re committing to before the contract is signed.

You may also like