Uptime SLA Math: 99.9% vs 99.99% Downtime Budgets

Every "nine" in an SLA sounds like a rounding error until you convert it into actual minutes of allowed downtime. The difference between 99.9% and 99.99% availability is the difference between an outage your team quietly fixes over lunch and one that barely registers. This article does the math so you can set realistic targets and defend them in a contract.

SLI, SLO, and SLA - the three letters people mix up

• SLI (Service Level Indicator): the actual measured metric, e.g., "percentage of successful HTTP checks over 5 minutes" or "p95 latency."
• SLO (Service Level Objective): the internal target for that indicator, e.g., "99.95% of requests succeed per month." This is what your engineering team is held to.
• SLA (Service Level Agreement): the external, often contractual, commitment to customers - usually a slightly looser version of your SLO, with defined penalties (credits, refunds) if missed.

A healthy practice is to set your SLO stricter than your SLA. If your SLA promises 99.9%, target 99.95% internally so you have margin before you owe customers credits.

The downtime budget table

"Availability" is just uptime divided by total time in a period, multiplied by 100. Flip that around and you get an error budget: the maximum downtime allowed while still meeting the target.

Reading this table honestly changes how you talk about SLAs. Going from 99.9% to 99.99% doesn't mean "10x better" in engineering effort - it usually means an order of magnitude more investment in redundancy, failover automation, and multi-region architecture, because you no longer have time for a human to notice and react manually.

How the math actually works

The formula is straightforward:

allowed_downtime = total_period_seconds * (1 - availability_target)

For a 30-day month (2,592,000 seconds) at 99.9%:

2,592,000 * (1 - 0.999) = 2,592 seconds = 43.2 minutes

Calculate it yourself for any period:

python3 -c "
period_seconds = 30*24*3600
target = 0.9995
print(period_seconds * (1 - target), 'seconds allowed downtime')
"

What counts as "down" - and why measurement method matters

Your SLA is only as good as how downtime is measured, and this is where vendors and customers often disagree. Key decisions to nail down:

• Check interval: if you only check every 5 minutes, you can miss a 3-minute outage entirely, understating real downtime.
• Consensus rule: is a single failed check from one region "down," or do you require multiple regions to agree? (See our uptime monitoring primer for how consensus works.)
• Excluded time: scheduled maintenance windows are typically excluded from SLA calculations - but only if properly announced with advance notice, often on a public status page.
• Partial degradation: does elevated latency without full failure count as downtime? Most SLAs don't cover latency at all unless explicitly stated.

Calculating credits

A typical SaaS SLA credit schedule looks like this:

To calculate whether you owe a credit, you need continuous, auditable uptime records - not a spreadsheet reconstructed after the fact. This is one of the most underrated reasons to run independent third-party monitoring: it produces a timestamped, external record of exactly when checks failed, which is far more defensible in a credit dispute than server-side logs the vendor controls.

Setting your own SLO: a practical checklist

• Pick an SLI that reflects what customers actually care about (successful request rate, not just "server process alive")
• Set your internal SLO stricter than any external SLA you publish
• Define your measurement window (rolling 30 days is common, avoids calendar-month reset gaming)
• Document what's excluded (planned maintenance, force majeure) and require advance notice for exclusions to count
• Use multi-region synthetic checks with a short interval so your measured downtime approximates reality
• Automate credit calculation from monitoring data rather than manual review
• Review your error budget burn rate weekly, not just at the end of the billing period

FAQ

What's the difference between SLO and SLA in practice?

SLO is internal and drives engineering priorities - if you're burning your error budget too fast, you slow down feature releases and focus on reliability. SLA is external and contractual, with financial consequences. They should use the same underlying SLI, but the SLA target is usually looser to leave margin.

Does scheduled maintenance count against my uptime SLA?

Almost always excluded, but only under specific conditions written into the contract - typically advance notice (e.g., 48 hours) and a maintenance window announced on a public status page. Unannounced or emergency maintenance usually does count against the SLA.

How often should I check my error budget?

Weekly at minimum for anything with a monthly SLA. Waiting until the end of the month to discover you've blown the budget removes any chance to course-correct.

Is 99.99% uptime realistic for a small team?

It's achievable but expensive: it requires automated failover, multi-region redundancy, and infrastructure that can recover in seconds without human intervention, since the entire monthly budget is under 5 minutes. Most small teams are better served by a well-monitored 99.9% target with fast alerting and manual response.

How do I prove my measured uptime to a customer during a dispute?

Independent, timestamped synthetic monitoring records - showing check results, regions, and response codes over time - are the strongest evidence, since they aren't derived solely from the provider's own server logs.