SaaS Uptime SLAs: How to Set Them and How to Hit Them

Your customer asks for 99.99% uptime. Your engineer says "we run on AWS, that should be fine." Six months later, the math has not worked out. You owe SLA credits. Sales is unhappy. Engineering is exhausted.

Setting an uptime SLA is a commitment, not a marketing claim. Here is how to think about what to promise and how to actually deliver it.

What the numbers actually mean

SLA tiers and their downtime budgets per month:

• 99.0%: 7 hours 18 minutes of allowed downtime per month.
• 99.5%: 3 hours 39 minutes.
• 99.9% (three nines): 43 minutes 49 seconds.
• 99.95%: 21 minutes 54 seconds.
• 99.99% (four nines): 4 minutes 22 seconds.
• 99.999% (five nines): 26 seconds.

Each additional nine is roughly 10x harder than the previous one. The architectural difference between "two nines" and "three nines" is significant. Between "three nines" and "four nines" is enormous. Between "four nines" and "five nines" is something only the largest infrastructure teams in the world reliably achieve.

What you can promise at your stage

Pre-product-market-fit (no enterprise customers): Do not set a public SLA. Run a status page. Aim for two nines internally.

Early enterprise (first 5-15 enterprise customers): 99.9% is achievable on managed cloud services with reasonable engineering investment. Standard tier for most B2B SaaS.

Scaling enterprise (50+ enterprise customers): 99.95% with serious investment in redundancy, deploy safety, and incident response. The jump from 99.9 to 99.95 typically requires multi-AZ deployment, blue/green deploys, and a real on-call practice.

Mission-critical enterprise (banking, healthcare, telecom): 99.99% requires multi-region active-active or active-passive architecture, automated failover, and a dedicated SRE function. This is a major investment, not a target you stumble into.

Promising more than you can deliver is worse than promising less. Customers respect honest SLAs. They penalize broken ones.

What "uptime" means in your SLA

Define this carefully in the contract. The phrase "99.9% uptime" can mean very different things.

Specifically, the SLA should define:

• What counts as "down." Total unavailability? Degraded performance? Specific feature unavailable? Define it.
• How measurement works. Customer-reported? Synthetic monitoring? Your monitoring? Whose tool wins in a dispute?
• What is excluded. Scheduled maintenance (with notice), customer-caused issues, force majeure, third-party outages (AWS, Stripe, etc.).
• Measurement window. Calendar month is standard. Trailing 30 days is sometimes used.
• Credit structure. Typically a percentage of monthly fees credited back, with a cap (usually 25-50% of monthly fees). Credits do not extend the term.

What it takes to actually hit 99.9%

Three nines is achievable on a single cloud region with the following:

• Multi-AZ deployment for the application tier and the database.
• Auto-scaling configured properly so traffic spikes do not cause outages.
• Health checks at the load balancer that pull bad instances out of rotation fast.
• Blue/green or canary deployment so bad deploys do not affect 100% of traffic.
• Real monitoring with alerts that fire fast (under 2 minutes for customer-facing issues).
• On-call rotation with documented runbooks.
• Database backups with tested restore. Failover for the primary database.
• Status page with public history.

None of these is exotic. All of them require deliberate work. Teams that wing it typically achieve 99% to 99.5%, which sounds close to three nines but is not.

The trap that kills most SLAs

Most missed SLAs are not from one big outage. They are from the cumulative effect of small ones: a 5-minute glitch every week is 240 minutes per year, which already exceeds the four-nines budget.

Track partial degradation, not just total outages. Aggregate over your measurement window. Look at your actual numbers, not the optimistic ones in the status page summary.

What to do if you miss

If you miss SLA, communicate proactively. Issue credits without making customers ask. The credit is rarely the largest cost; the trust damage is. Customers who feel respected after an incident often stay. Customers who feel ignored leave. And before you commit to 99.9% in an enterprise contract, make sure the infrastructure behind it can actually hold the number.

Set the Internal Target Above the Contractual One

The number in your contract and the number your engineering team aims at should not be the same number. If you promise 99.9% and target 99.9%, you have no margin for the ordinary bad month, and you will pay credits on a quarter that was basically fine.

The working approach is an internal service level objective set roughly one tier tighter than the contractual commitment. Promise 99.9%, target 99.95%, and treat the difference as the buffer that absorbs a genuinely unlucky incident. The gap between those two numbers is what an error budget measures: at 99.95% internal target you have about 22 minutes of unavailability per month before engineering priorities change. When the budget is spent, feature work pauses and reliability work starts, and that rule needs to be agreed with the product leadership before you need it rather than argued about during an incident review.

This also gives you a defensible answer when sales asks for a tighter number. The question is not whether you can survive a good month at 99.99%. It is whether your worst month in the last twelve would have cleared it. Pull the actual figures for the trailing year and read them out. That conversation is much shorter with data.

Measure From Where the Customer Sits

Most availability disputes are measurement disputes. Your load balancer reports healthy targets while a customer's users get errors, and both parties believe their own dashboard.

Measure availability from outside your infrastructure, using synthetic checks that exercise a real user path rather than pinging a health endpoint that returns 200 regardless of whether the database is reachable. Health checks that only confirm the process is alive are the most common reason a real outage shows up as green. Your synthetic check should log in, read something, and write something, from at least three geographic locations, with a failure threshold that requires two consecutive locations to fail before an incident is declared.

Then supplement it with the real signal, which is the percentage of successful requests against total requests, measured at the edge, sliced per customer. In a multi-tenant system, a single tenant can be completely unavailable while aggregate availability reads 99.99% because they are two percent of traffic. That tenant is the one with the SLA, and if you can only report on the aggregate, you cannot answer their claim. Per-tenant availability is a schema decision in your metrics pipeline, and adding the tenant label after the fact is painful, so add it now.

Write into the contract which measurement governs. The cleanest language names your monitoring as authoritative, requires you to publish the monthly figure without the customer asking, and gives the customer a defined window to dispute with their own evidence.

Dependencies Multiply, They Do Not Average

If your login path requires your application, your database, your identity provider, and a payment API, and each is independently available 99.95% of the time, the serial availability of that path is roughly 99.8%. You have promised a number your architecture cannot produce, and no amount of engineering effort on your own tier fixes it.

Do the arithmetic before the commitment. List every third party in the critical path, read their published SLA, and multiply. Then reduce the list. The usual moves are caching identity provider decisions so a brief outage does not lock everyone out, making non-essential calls asynchronous so a slow analytics vendor cannot hold a request open, adding a circuit breaker with a defined degraded behavior, and removing dependencies from the login and read paths entirely even if that costs some functionality.

Be careful with the third-party exclusion clause. Excluding cloud provider outages is standard and buyers accept it. Excluding every vendor you chose is not, and a sophisticated procurement team will strike it. Their reasoning is fair: you selected those vendors, so their reliability is part of your product. Expect to keep the exclusion for infrastructure and lose it for application-layer services.

What Enterprise Buyers Ask for Beyond the Percentage

The uptime number is the headline, and it is rarely the only commitment in the schedule. Come prepared for support response times by severity, with a definition of each severity that you wrote rather than one you inherited from their template. Expect recovery time and recovery point objectives, and know that RTO and RPO are backup and failover commitments, not availability ones, so meeting 99.9% says nothing about whether you can restore within four hours. Expect a maintenance window clause specifying advance notice, often ten business days, and a cap on total maintenance hours per quarter. Expect a chronic failure clause giving the customer termination rights if you miss in two or three consecutive months, which is the term that actually has teeth, because credits are small and termination is not.

If you carry the availability criterion in a SOC 2 report, note that the two artifacts have to agree. Auditors test capacity monitoring, backup restoration, and recovery procedures against what you claim publicly. A published 99.99% commitment with no evidence of tested failover is an uncomfortable conversation during fieldwork, and buyers do read both documents.

When Not to Sell a Tighter SLA at All

We spend more time talking teams out of higher availability commitments than into them, so here is the honest position.

If a customer demands 99.99% and your product is not in a path where minutes of downtime cause them measurable loss, ask what the number is for. Often it is a procurement default copied from a template with no owner behind it. Offering 99.9% with faster support response, a published status page with real history, and a credit structure that pays out automatically is frequently accepted, and it costs you a fraction of what multi-region active-active costs.

If the deal is worth less annually than the infrastructure spend required to support the number, do not take the term. Multi-region architecture roughly doubles infrastructure cost, adds data residency and replication lag complexity, and requires an on-call practice you may not have. A $60,000 contract does not fund that.

If you are pre-product-market-fit, a public SLA is a liability with no upside. Run a status page, publish incidents honestly, and let that be the trust signal. Buyers at that stage are betting on the team.

And if what you actually need is to know whether your current architecture can hold a number before you sign it, that is a short piece of work rather than a project. Tell us the number the customer asked for and what your last twelve months looked like, and we will tell you whether the gap is a configuration change, a quarter of engineering, or a commitment you should decline. If the answer turns out to be ongoing reliability and security work, a retainer is usually the cheaper structure.