Uptime percentages are how SaaS providers talk about reliability, but the numbers don’t mean much without translating them into something concrete. 99.9% sounds close to 99.99%, but the difference between them is the difference between eight and a half hours of downtime per year and fifty-two minutes. For an enterprise customer running business-critical workflows on your platform, that gap matters.
This post covers the arithmetic behind uptime commitments, what counts as downtime, how measurement windows affect your exposure, and what infrastructure investment is required to move between tiers.
The Numbers
| Uptime | Downtime per year | Downtime per month |
|---|---|---|
| 99.0% | 87.6 hours | 7.3 hours |
| 99.5% | 43.8 hours | 3.6 hours |
| 99.9% | 8.76 hours | 43.8 minutes |
| 99.95% | 4.38 hours | 21.9 minutes |
| 99.99% | 52.6 minutes | 4.4 minutes |
| 99.999% | 5.26 minutes | 26.3 seconds |
A few things stand out. First, the jump from 99.9% to 99.99% is not a rounding difference. It’s the difference between a major incident that takes two hours to resolve and staying within your budget for the entire year. Second, 99.999% — the “five nines” standard that large infrastructure providers advertise — allows less than 27 seconds of downtime per month. Almost no B2B SaaS company at seed or Series A can meaningfully commit to this, and none should.
How to Calculate Uptime
The standard formula:
Uptime % = ((Total minutes in period - Downtime minutes) / Total minutes in period) × 100
For a 30-day month, total minutes = 43,200. If you had 45 minutes of downtime:
((43,200 - 45) / 43,200) × 100 = 99.896%
That misses a 99.9% commitment by a fraction. One incident of just under an hour puts you in breach for the month.
Your SLA should specify this formula explicitly, including how partial minutes are counted. Rounding conventions matter when you’re close to the boundary.
What Counts as Downtime
This is where SLA negotiations get substantive. The definition of downtime determines how often you’re technically in breach, and the gap between a narrow and broad definition is significant.
Complete unavailability is the narrowest definition: the service is unreachable for all users. This is the most provider-friendly position. A partial outage affecting one region or one customer segment doesn’t count.
Partial unavailability extends the definition to scenarios where a subset of users cannot access the service. If 30% of your users are on an affected database shard, do those 30% count? Under partial unavailability, yes.
Degraded performance is the broadest definition: the service is technically reachable but materially slower than normal. This is the most customer-friendly position and the hardest for providers to manage, because performance degradation is continuous rather than binary. If you accept this definition, you need a precise threshold: response times exceeding X milliseconds for Y% of requests over a Z-minute window, measured by a specified monitoring tool.
The practical recommendation: define downtime as complete unavailability for your baseline SLA, with an explicit carve-out for degraded performance unless you have mature observability infrastructure to measure and dispute it. If enterprise customers push for a degraded performance definition, make sure the threshold is specific and the measurement methodology is yours, not theirs.
Measurement Windows: Monthly vs. Annual
Most SLAs measure uptime on a monthly basis. Annual measurement is more favorable to providers — a bad month gets averaged across eleven good ones — but enterprise buyers almost universally require monthly measurement, and for good reason. A customer whose service was down for six hours in March doesn’t care that your annual uptime was 99.95%.
Monthly measurement means your credit obligation resets every month. A bad January doesn’t carry over to February. It also means your uptime commitment needs to be achievable in any given month, not just on average across the year.
One nuance worth building into your SLA: how to handle months with scheduled maintenance. If you take a two-hour maintenance window in a 30-day month, that’s 0.139% of the period. Whether that counts against your uptime depends entirely on whether your maintenance exclusion is drafted cleanly. See SLA Exclusions: What Shouldn’t Count Against Your Uptime for how to structure this.
Infrastructure Tiers and Achievable Uptime
Uptime is an output of your architecture, not a number you choose independently. The following maps common infrastructure setups to realistic uptime ceilings.
| Infrastructure setup | Realistic uptime ceiling |
|---|---|
| Single-region PaaS, no redundancy | 99.5% to 99.9% |
| Single-region, managed database with automated failover | 99.9% |
| Multi-region active-passive with manual failover | 99.9% to 99.95% |
| Multi-region active-passive with automated failover | 99.95% |
| Multi-region active-active, redundant data layer | 99.99% |
These are ceilings, not guarantees. Your actual uptime depends on your deployment practices, dependency reliability, and incident response speed. A single bad deploy on a single-region setup can consume your entire monthly budget in one event.
The honest exercise: pull your monitoring data for the last 12 months and calculate your actual uptime. That number is your baseline. Your SLA commitment should sit at or below it until you’ve made the infrastructure investments to move it higher.
The Engineering Investment Required to Move Between Tiers
Moving from 99.9% to 99.99% is not a configuration change. It requires meaningful architectural work.
From 99.5% to 99.9% is often achievable with better deployment practices: automated rollbacks, blue-green deployments, and improved monitoring. No major infrastructure change required.
From 99.9% to 99.95% typically requires database redundancy and automated failover. If your primary database goes down and recovery is manual, you will burn through your monthly budget in a single incident.
From 99.95% to 99.99% requires multi-region architecture with automated failover and a data replication strategy that keeps regions in sync. This is a significant engineering project, not a weekend task. It also introduces consistency tradeoffs that affect your application’s behavior.
Beyond 99.99% requires active-active multi-region deployments with no single points of failure, including at the application, database, and networking layers. Very few B2B SaaS companies at seed or Series A have this, and fewer still need it to close enterprise deals.
The business implication: if a customer’s RFP requires 99.99% and your architecture supports 99.9%, that’s a conversation about investment timeline and contract structure, not a reason to sign a commitment you can’t honor. An honest 99.9% commitment with a clear roadmap to 99.99% is more credible than a 99.99% commitment that breaks in the first quarter.
No Boiler provides self-service legal document generation and educational content. This material and our service is not a substitute for legal advice. Please have a qualified attorney review any documents before relying on them. No Boiler is not a law firm, and communications with us do not create an attorney-client relationship or carry any expectation of confidentiality. Use of our platform and content is governed by our Terms of Service and Privacy Policy.