Free lesson · System Design Crash Course

Availability: Nines, SLAs, and What 99.9% Actually Allows

Easy10 min readsystem-designhlddistributed-systems

Lesson 2.3 - Availability: Nines, SLAs, and What 99.9% Actually Allows

The nines lesson.

Here's a question that sounds simple but turns out to have a precise answer. Your manager says: "Our service should be highly available - let's aim for 99.9% uptime." You nod. Sounds good. 99.9% is high. Two months later, the service is down for 30 minutes one afternoon, then for another hour the following week. Your manager is angry. You point out you're still above 99.9%. Are you?

Maybe. Maybe not. The math turns out to be more interesting than most people realize. And the practical implications - what 99.9% actually allows you to do, what it costs to push for more nines, how dependencies compound - affect every system you'll ever design.

By the end of this lesson, you'll know precisely what 99%, 99.9%, 99.99%, and 99.999% mean in real downtime; the difference between SLA, SLO, and SLI; why each additional nine costs exponentially more than the previous one; and how to reason about availability across dependencies.

What Availability Actually Means

Let me start with the basic definition. Availability is the fraction of time a system is operational and responding correctly.

Some clarifications because the definition hides nuance:

"Operational" is fuzzy. Does a slow service count as "available"? Most definitions say no - a service that's so slow it times out user requests is effectively unavailable, even if it's technically responding. So availability often includes some performance threshold, like "responds within 1 second."

"Responding correctly" also matters. A service returning 500 errors at full speed isn't available, even though it's responding. Availability usually means "successful responses," with success defined per service.

"Fraction of time" can be measured over different windows. Most SLAs use monthly windows. Some use yearly. The choice affects what the number really means.

A common operational definition:

$\text{Availability} = \frac{\text{successful responses}}{\text{total requests}}$

Or sometimes:

$\text{Availability} = \frac{\text{operational time}}{\text{total time}}$

These give similar but not identical results depending on traffic patterns. Both are used in practice.

The Nines

When availability is given as a percentage, you'll hear "nines" - shorthand for the number of 9s in the percentage.

• 99% = "two nines"
• 99.9% = "three nines"
• 99.99% = "four nines"
• 99.999% = "five nines"
• 99.9999% = "six nines"

Each additional nine sounds like a small bump in the percentage, but the meaning compounds. Let me show you what each actually allows in real downtime.

Look at this table for a moment. Some of those numbers are striking.

Three nines (99.9%) sounds great in a meeting, but it means 8.76 hours of downtime per year is OK. That's a full workday. If you have a system at 99.9%, you can be down all of one afternoon without violating it. It also means 43 minutes per month - pretty generous.

Four nines (99.99%) is significantly tighter. 52 minutes per year. About 4 minutes per month. One bad deployment that takes 10 minutes to recover blows your monthly budget.

Five nines (99.999%) is famously hard. 5 minutes per year. 26 seconds per month. You can't even page-out an on-call engineer in 26 seconds. Five nines is largely beyond what you can sustain with human-in-the-loop incident response.

Six nines is real-time-systems territory - telecom equipment, life-safety systems, financial trading floors. Not what your typical web service aims for.

A Practical Way to Read SLA Numbers

When you see a company advertising "99.9% uptime SLA," translate it like this:

"We may be down for up to 43 minutes this month and still satisfy our promise."

Or for "99.99% uptime":

"We may be down for up to 4 minutes this month and still satisfy our promise."

This translation grounds the marketing number in reality. Marketing copy often promises five or even six nines. Look at the actual SLA. Hyperscalers are honest about what they commit to.

A few real public SLAs:

• AWS S3 Standard storage: 99.9% (three nines). Notice - NOT four or five nines. Even Amazon doesn't commit contractually to higher than that.
• Google Cloud Storage: 99.95% for multi-region (Standard storage).
• AWS EC2: 99.99% for regions (with multi-AZ design).
• Azure Virtual Machines: 99.9% to 99.99% depending on configuration.

These are the public commitments from companies with thousands of engineers. They don't commit to higher than four nines for most services. If a smaller team promises higher than 99.9% to a customer, they should think very hard about whether they can actually deliver.

SLA vs SLO vs SLI

Three related but distinct terms. Worth knowing them precisely.

SLI (Service Level Indicator) = the measurement.

• "Percentage of HTTP requests that return 2xx or 3xx within 500ms."
• This is what you actually measure. A specific, quantifiable thing.

SLO (Service Level Objective) = the target you set internally.

• "We aim for 99.95% successful requests per month."
• This is what your team commits to internally. Used to drive engineering work, incident response, prioritization.

SLA (Service Level Agreement) = the contractual commitment with consequences.

• "If we deliver less than 99.9% in a month, we credit the customer 10%."
• This is what your customer-facing contract says. Usually a more lax target than your SLO, with financial consequences attached.

The standard pattern: SLA < SLO < actual performance. You set a contractual SLA. You aim higher than that internally (the SLO). Your actual performance is hopefully higher than your SLO. The gaps protect you.

Example for a hypothetical service:

• SLA: 99.9% (contractual; customers can claim credits if missed)
• SLO: 99.95% (what the engineering team commits to internally)
• Actual: 99.97% (what the service usually delivers)

If actual performance dips to 99.96%, the team starts to worry - they're approaching their SLO. If it dips to 99.91%, they're in serious trouble - close to violating the SLA. The buffer between SLO and SLA is what gives the team time to react before customer impact.

This SLO-SLA-SLI framework is most carefully articulated in Google's Site Reliability Engineering book (free online - see references). If you want to take reliability seriously, the chapters on SLOs are the canonical reference.

Why Each Nine Costs Exponentially More

Here's a less-obvious truth: moving from 99% to 99.9% is one engineering project. Moving from 99.9% to 99.99% is a much bigger one. Moving from 99.99% to 99.999% is sometimes an existential undertaking.

Each additional nine roughly divides your allowed downtime by 10, while requiring proportional (or greater) investment in:

• Better monitoring (you need to detect failures faster)
• Better automation (humans can't respond fast enough)
• Better testing (every release becomes higher-stakes)
• Better infrastructure (redundancy, failover, multi-region)
• More engineering staff (more 24/7 on-call coverage)

This shows up as a roughly logarithmic cost curve:

graph TD
    A["99%<br/>Easy"]
    B["99.9%<br/>Achievable<br/>with standard practices"]
    C["99.99%<br/>Requires deliberate<br/>engineering investment"]
    D["99.999%<br/>Requires extensive<br/>automation + redundancy"]
    E["99.9999%<br/>Specialized domains only<br/>(telecom, life safety)"]

    A -->|"10x more reliable<br/>1x more cost"| B
    B -->|"10x more reliable<br/>3-5x more cost"| C
    C -->|"10x more reliable<br/>10x more cost"| D
    D -->|"10x more reliable<br/>30x+ more cost"| E

    style A fill:#34d399,stroke:#10b981,color:#000
    style B fill:#84cc16,stroke:#65a30d,color:#000
    style C fill:#fbbf24,stroke:#f59e0b,color:#000
    style D fill:#fb923c,stroke:#ea580c,color:#000
    style E fill:#fb7185,stroke:#f43f5e,color:#000

A diagram showing the relative cost of each additional nine of availability. Moving from 99% to 99.9% is roughly the same cost  - it's achievable with standard practices like monitoring, basic redundancy, and reasonable incident response. Moving from 99.9% to 99.99% costs about 3 to 5 times more  - you need deliberate engineering investment in automation, failover, and faster incident response. Moving from 99.99% to 99.999% costs roughly 10 times more again  - you need extensive automation because humans cannot respond in the required time windows. Going beyond five nines is generally a specialized engineering domain  - telecom, life safety, financial trading. The cost curve is roughly logarithmic: each additional nine is dramatically more expensive than the previous one. This is why most companies stop at three or four nines  - the next nine is rarely worth the cost.

The implication for design: don't promise more nines than you can sustainably deliver. A team committing to 99.99% needs to budget for the engineering investment that implies. Sometimes the right answer is to commit to 99.9% but actually deliver 99.95% - under-promise, over-deliver.

There's also a "diminishing returns" argument. If your users tolerate 30 minutes of downtime per month with 99.9% availability, will they meaningfully care about the difference between 4 minutes (99.99%) and 30 seconds (99.999%)? For most products, the marginal user happiness from each additional nine drops fast. The cost-benefit usually favors stopping at 99.9% or 99.99% for typical web services.

How Availability Composes Across Dependencies

This is where things get interesting. If your service depends on multiple other services, your availability is the product of theirs.

Suppose your service requires three downstream dependencies (a database, a cache, an authentication service). Each has 99.9% availability. What's your availability?

$\text{Your availability} = 0.999 \times 0.999 \times 0.999 \approx 0.997$

That's 99.7%. You can't be more available than your dependencies - and you can be quite a bit less. Each additional dependency drops your availability.

This composition is multiplicative, not additive, because failures are independent (or close to it). The probability that all three are working at any moment is the product of each individually working.

With 5 dependencies each at 99.9%:

$0.999^5 \approx 0.995 = 99.5%$

With 10 dependencies each at 99.9%:

$0.999^{10} \approx 0.990 = 99.0%$

So a system that depends on 10 three-nine services struggles to hit two nines itself. This is one of the underrated reasons that microservice architectures are operationally harder - the dependency graph multiplies availability.

How to fight this:

1. Reduce dependencies. Fewer hard dependencies = better composed availability. Sometimes you can co-locate data or use caches to avoid a service call.

2. Make dependencies optional where possible. If your homepage can render without the recommendations service (it just shows a default carousel), the recommendations service isn't a hard dependency for availability. Graceful degradation directly improves availability math.

3. Improve individual dependency availability. Each nine you can squeeze out of a dependency benefits everyone depending on it.

4. Use parallel dependencies (any-of patterns). If you can satisfy a request with any of three available replicas, your availability for that piece is much higher than for any individual replica.

Designing systems with availability composition in mind is something senior engineers do almost automatically. They look at a design and immediately ask: "How many hard dependencies are there? What's each one's availability?" Then they ballpark the achievable composed availability.

Mean Time Between Failures and Mean Time To Recovery

Two more vocabulary words you'll hear in availability discussions.

MTBF (Mean Time Between Failures) = how long the system runs between outages. If your system has one outage every 6 months on average, MTBF is 6 months.

MTTR (Mean Time To Recovery) = how long it takes to recover from an outage. If your average outage lasts 20 minutes, MTTR is 20 minutes.

Availability can be expressed as:

$\text{Availability} = \frac{\text{MTBF}}{\text{MTBF} + \text{MTTR}}$

This formula makes the engineering trade-off clear: you can improve availability either by failing less often (increasing MTBF) or by recovering faster (reducing MTTR). Both work.

Most teams discover that reducing MTTR is more achievable. Failures are hard to prevent entirely. But you can almost always reduce recovery time - through better monitoring, better automation, better runbooks, better deployments. The single highest-leverage availability investment for most teams is reducing MTTR.

A practical example: suppose your service has outages averaging 30 minutes (MTTR = 30 min) every two weeks (MTBF = 14 days). Availability is:

$\frac{14 \times 24 \times 60}{14 \times 24 \times 60 + 30} = \frac{20160}{20190} \approx 99.85%$

About 99.85% - between three and four nines. Now if you cut MTTR to 5 minutes (faster detection, better runbooks):

$\frac{20160}{20160 + 5} \approx 99.97%$

Without preventing a single outage, you jumped from 99.85% to 99.97% - past four nines. That's a huge availability gain from operational improvements alone.

This is why companies invest so heavily in observability and on-call tooling. Detection-to-recovery time is the lever.

The Honest Reality of Availability Reporting

A few honest observations from the field:

Companies report availability in self-serving ways. They might exclude "planned maintenance" from their downtime numbers. They might define "available" loosely (a service returning errors fast might count as "responsive"). They might measure only certain endpoints. Reported numbers should be read skeptically.

Real availability is hard to measure objectively. Should partial outages count? What about regional outages affecting a fraction of users? What about slow performance that drives users away? Different measurement choices give very different numbers.

Cloud providers' "availability zones failures" are common. The "five-nines" reputation of AWS or Google Cloud is at the regional level - using one availability zone gets you much less. Multi-AZ design is required to actually get the high availability the marketing claims.

Status pages lie. Companies are slow to update them. If you're investigating a third-party outage, don't trust the status page - check social media, where users report problems in real time.

Six Takeaways from This Lesson

1. Availability is a percentage of time a system is operational. Measured per minute, hour, month, or year - typically reported monthly.

2. The "nines" framework matters. 99% allows 7+ hours of monthly downtime. 99.9% allows 43 minutes. 99.99% allows 4 minutes. 99.999% allows 26 seconds.

3. SLI, SLO, SLA are distinct. SLI is the measurement. SLO is the internal target. SLA is the customer-facing contract with consequences. Usually SLO is set higher than SLA to provide a buffer.

4. Each additional nine costs exponentially more. The cost curve isn't linear - pushing from 99.9% to 99.99% is much harder than pushing from 99% to 99.9%.

5. Availability composes multiplicatively across dependencies. A service depending on 10 three-nine services struggles to hit two nines itself. Reducing dependencies and using graceful degradation are the main defenses.

6. MTTR matters more than MTBF. Improving recovery time gives most teams more availability gain than preventing failures. Invest heavily in monitoring, automation, and runbooks.

Try It

Exercise: Warmup (10 minutes). Pick a service you work on or use frequently. What's your honest guess of its monthly availability? How would you measure it precisely?

Exercise: Core (20 minutes). Find the SLA pages for three cloud services you use (AWS S3, GCP Storage, an API your service depends on). Note their committed availability and read the terms carefully - what counts as downtime, what excuses exist, what compensation is offered.

Exercise: Stretch (45 minutes). Read Google SRE Book Chapter 4: Service Level Objectives. Then for a service at work, draft what its SLI, SLO, and SLA should be. What would you measure? What target would you set internally? What would you commit to externally?

What's Next

Lesson 2.4 turns to consistency - a word that has a precise technical meaning in distributed systems and gets confused with several other meanings. We'll preview the consistency spectrum from linearizable to eventual, and you'll learn how to read any database's documentation to find where it sits.

Back to System Design Crash Course