Application Availability: How Many Nines Do You Need?

The 2am page from a decision that looked fine in the room

The design review had a clean answer for it: one Redis instance, in front of the read path, no cluster, no replica, no fallback to the database if it went dark. We'd talked about a failover pair. Someone — I don't remember if it was me or someone agreeing with me — said the team was small, the traffic was modest, and a replicated cache was solving a problem we didn't have yet. It sounded disciplined. It sounded like the kind of restraint I now write about under a different name: not over-engineering for scale you haven't earned.

It held for months. Then the instance died. Not gracefully, not with a warning, just gone. And every read path that assumed Redis would answer started timing out against a database that had never been sized to take that load directly. No circuit breaker. No shed path. No cached-stale-is-fine fallback. Just every request stacking up behind a resource that used to be fast and was now the whole incident.

The page came at 2am. I was the one who'd have to trace it, because I was the one who'd approved "no fallback" as the simple version. There is a specific kind of tired where you're staring at connection-pool exhaustion logs and doing mental math on how many minutes until the database itself falls over, and the thing you feel isn't panic — it's recognition. This was the exact failure mode the failover conversation had been about, and I'd talked myself out of paying for it because it looked unnecessary on a Tuesday afternoon in a design review.

That's the gap this whole piece is about. A design review optimizes for the clean diagram: fewer boxes, one obvious path, nothing to explain to a skeptical peer. A 2am incident optimizes for one thing only — can a tired human trace this and close it out without calling the person who built it. Those are different tests. Most teams grade their architecture on the first one and get graded, eventually, on the second.

And most teams are pointing that judgment at the wrong number. They're chasing a higher availability percentage — three nines, four nines, the mythical five — when the number that actually determines how bad that night gets is how fast the system, and the human on it, can recover. Here are the nines, decoded honestly, and where the math says to stop paying for the next one.

Availability, uptime, and reliability are not the same word

These get used interchangeably in status pages and incident reviews, and the conflation costs people.

Uptime is the crudest measure: is the process running. A server can be up, technically, while every request against it times out.

Availability is whether the system is usable by someone who needs it, right now. It accounts for latency, partial failure, and degraded responses, not just whether the process didn't crash. A system with 99.9% uptime and a P99 latency of 30 seconds is up. It is not available to anyone who gave up waiting.

Reliability is closer to an MTBF concept — how much time passes, on average, between failures. A system can be reliable (fails rarely) and still take a long time to recover when it does fail, which drags availability down even though the failure rate looks fine on a chart.

The distinction matters because teams optimize the metric they're measuring. If you're tracking uptime, you'll ship a system that never crashes and quietly fails half its requests under load — technically up, functionally unavailable, and nobody's dashboard will tell you.

How availability is actually calculated

Two formulas, and they're doing different jobs.

Time-based availability:

A = uptime / (uptime + downtime)

This is the retrospective version — what actually happened over a period, expressed as a fraction.

Component-based availability:

A = MTBF / (MTBF + MTTR)

MTBF is mean time between failures. MTTR is mean time to recovery. This one is predictive, and it's the more useful formula for an architect, because it splits availability into two levers you can actually push on separately: how often things break, and how fast you close the incident once they do.

Worked example. Say a service has an MTBF of 1,000 hours and an MTTR of 2 hours:

A = 1000 / (1000 + 2) = 0.998 → 99.8%

Now do the two levers separately. Halve the MTTR to 1 hour, keeping MTBF at 1,000:

A = 1000 / (1000 + 1) = 0.999 → 99.9%

Instead, double the MTBF to 2,000 hours, keeping MTTR at 2:

A = 2000 / (2000 + 2) = 0.999 → 99.9%

Same result — and that's not a coincidence of the numbers I picked, it's an algebraic identity: halving MTTR and doubling MTBF move availability by the same amount. But doubling MTBF means making the system fail half as often, which takes new redundancy, new hardening, new testing — usually months of work and a real cost. Halving MTTR means better runbooks, better alerting, a faster rollback path, a dashboard that tells the on-call exactly where to look. It's the cheaper lever, the faster lever, and it's the one you actually control day to day. Most teams instinctively reach for the expensive lever because it feels more like "real engineering." The math says the other one is where the leverage is.

Decoding the nines: what a 9 actually costs you

Here's what each availability tier actually allows, in time you're permitted to be down:

Read that table again at the bottom row. Five nines gives you 26 seconds a month. You cannot page a human, wait for them to open a laptop, read a dashboard, and type a command inside 26 seconds. Nobody's runbook is that fast, and nobody's Slack notification lands in under a minute, let alone gets acted on.

That reframes what "five nines" even means. It isn't a target you hit by trying harder or hiring a better on-call rotation. It's a statement that recovery has to be fully automated — instant failover, no human decision in the loop, detection and remediation both machine-speed. If your plan for hitting five nines still has a step where someone gets paged, you haven't designed for five nines. You've designed for four nines with better intentions.

Why the next nine costs roughly 10x — and when to stop buying it

Going from two nines to three is mostly discipline: monitoring, basic redundancy, and a deploy process that doesn't take the whole system down. Going from three to four usually means multi-AZ infrastructure and failover you've actually tested under load, not just diagrammed. Going from four to five is a different category of commitment — multi-region active-active, with automated failover and no human in the decision path. And that last step is as much an organizational cost as a technical one: it means a 24/7 team large enough that nobody burns out covering the rotation.

The SRE rule of thumb is that each nine costs roughly an order of magnitude — 10x — more than the last, and in practice it holds up: more redundant infrastructure, more edge cases in the failover logic, more people, more cost, and more of the specific kind of fatigue that comes from an on-call rotation nobody can sustain. I've done this to myself — built for the reliability tier I imagined we'd need instead of the one our actual traffic and business risk justified, and sunk months into infrastructure a product with three real users never came close to stressing. That's over-engineering with a more respectable name on it, and availability targets are one of the places it hides best, because "more available" always sounds virtuous in a planning meeting.

The honest question isn't "can we afford another 9." It's "does the business actually lose money, trust, or customers in the gap between the nine we have and the nine we're about to buy." For most products — most internal tools, most B2B SaaS, most systems where a person can retry a request — the answer past four nines is no. The saved effort belongs somewhere with a better return: faster recovery, better observability, and knowing when to stop optimizing a number that's already good enough for the business it serves.

The dependency trap: your architecture caps your nines before your effort does

Availability multiplies across dependencies in series. This is the part most teams miss entirely, and it's the reason a system built out of individually solid components can still have a mediocre composite number.

Five services, each individually a respectable 99.9%, wired in series. Composite availability is the product:

0.999 × 0.999 × 0.999 × 0.999 × 0.999 ≈ 0.995 → 99.5%

That's roughly 1.8 days of downtime a year. Every service in that chain is individually rated at three nines — 43.8 minutes of downtime a month — yet the system they form together lands at 99.5%, dragged down toward the two-nines tier by nothing more than the length of the chain. Every dependency you add on the critical path is a tax on your ceiling, not just a risk on your list. You can have a flawless SRE team and a well-run on-call rotation and still be capped at 99.5% because of how many services sit between the request and the response, none of them individually to blame.

The way you claw availability back isn't heroics on any single component. It's parallel paths — redundancy that turns a series dependency into something with an alternate route, a cache that can serve stale instead of failing closed, a queue that can absorb a downstream outage instead of propagating it upstream in real time. Your dependency graph decides your availability ceiling before your engineering effort gets a vote.

What actually counts as downtime — the honest-measurement problem

Most availability numbers you see on a status page are flattering by design, and not always dishonestly — just by convention.

Planned maintenance often gets excluded from the calculation, which is fine if you tell customers and misleading if the "planned" window is the thing that actually broke their workflow. Partial outages — a checkout that works but is slow, a search feature that's degraded but not down — frequently don't count at all, because most measurement happens at the server, not at the user's edge. A request that technically returned 200 after 12 seconds counts as "up" in most monitoring setups and reads as "broken" to the person who abandoned the page after three.

There's also a duration-blindness problem. A 5-minute outage during a low-traffic window and a 5-minute outage during your peak aren't the same incident, even though they show up identically in an annual availability percentage. If your measurement doesn't weight for when it happened and who it happened to, your "99.95% this quarter" is true and almost meaningless.

The fix is measuring from the user's actual vantage point: synthetic checks that hit the same edge your customers hit, real-user monitoring that captures the slow-but-technically-successful requests, and a definition of "down" that includes degraded, not just dead.

SLA, SLO, SLI, and the error budget: the pivot that actually matters

Four terms get used loosely, and the loose usage is where the friction between engineering and product comes from.

SLI (service level indicator) is the raw measurement — request latency, error rate, availability, whatever you're actually tracking.

SLO (service level objective) is your internal target for that indicator — the number your team is actually trying to hit.

SLA (service level agreement) is the external, contractual promise, usually to a customer, and it's almost always looser than your SLO. You keep a buffer between what you promise externally and what you target internally, because you don't want a bad week to also be a breach of contract.

Error budget is where this stops being definitions and starts being a decision-making tool. If your SLO is 99.9% over 30 days, your error budget is the inverse: 0.1% of that window, or 43.2 minutes, that you're allowed to spend on failure without missing the target.

Error budget = (1 − SLO) × time window
             = 0.001 × 30 days × 24 hours × 60 minutes
             = 43.2 minutes

(The nines table above reads 43.8 minutes a month because it divides an average year by twelve; here I've used an explicit 30-day window. Same target, slightly different window length.)

That number is the actual pivot of this whole piece. An error budget converts "don't break production" — an anxiety, not a decision — into a spendable number both engineering and product can look at together. Ship the risky migration this week? Fine, if you've got 38 of your 43 minutes left. Running low with two weeks left in the window? That's the actual, defensible reason to freeze risky deploys — not a gut feeling, a number everyone agreed to in advance. The error budget is what turns availability from a religion into a resource allocation.

Best practices that hold up at 3am, not just in the design review

None of this installs once like a checklist. These are decisions that show up differently depending on whether you're optimizing for the review or the pager.

Eliminate single points of failure, and be honest about what "single" means — a load balancer with one healthy instance behind it is a SPOF wearing a redundant-sounding name. Build graceful degradation and load shedding before you need them; a system that can serve a stale cache or a reduced feature set under load is available in a way a system that returns a 500 under the same load is not. Make retries idempotent and back off exponentially, because a naive retry storm during a partial outage is how a recoverable incident turns into a full one. Invest in observability that shortens MTTD, because you cannot recover from a failure you haven't detected yet, and the clock on your error budget is running the entire time you're blind to the incident. Write runbooks that assume the author isn't on the call.

That last one is the whole argument in one line, and it's the same discipline I've written about for the 3am-fixability test applied to code someone else's model wrote: the architecture that survives is the one the on-call can act on without a call to the person who designed it. Recoverability outranks reliability past a certain point, because reliability only tells you how rarely you'll be tested, and recoverability tells you what happens when you are.

The outage that actually hurts is the correlated one

More nines on a status page doesn't mean a better product. It sometimes just means a better-measured one, or a shorter reporting window since the last incident.

The outages that actually damage trust aren't the small, independent failures your redundancy was built for. They're the correlated ones — the single event that takes out several of your "redundant" paths at once because they all shared a hidden dependency nobody mapped. I've written before about a cache stampede that caused a 19-minute outage at scale, the kind of failure where every layer of caching you built for resilience becomes the exact mechanism that synchronizes the failure across your entire fleet at once. Your redundancy plan is only as good as your understanding of what it doesn't actually decorrelate.

A status page that reads "100% this month" is sometimes real discipline. It's sometimes also a measurement artifact — a monitor that doesn't check the path your users actually take, or a maintenance window that got quietly excluded. Treat every clean month as a hypothesis to test, not a result to celebrate.

The turn: pick the target the business needs, then stop

Here's the actual sequence, in order. Figure out what the business genuinely loses — revenue, trust, contractual exposure — in the gap between your current availability and the next tier up. Set your SLO there, not at the ceiling of what's technically possible. Give that SLO an error budget, and let it govern deploy risk instead of a vibe. Then take everything you were about to spend chasing the next decimal point and put it into MTTR: better runbooks, faster detection, automated failover for the failure modes that actually recur, architecture your on-call can act on without calling you.

The fourth nine is usually a defensible business decision — real money, real customers, a real gap worth closing. The fifth nine is a lifestyle: a 24/7 team, multi-region infrastructure, and an operational culture built entirely around a failure window too short for a human to matter in it. Most teams reading this don't need the lifestyle. They need the system their on-call can fix at 3am without the person who built it — which was true the night mine paged me, and it's the reason I still open every design review with that question before I ask if it's elegant.

What to do Monday morning

• Pull your last 90 days of incident data and calculate your actual MTTR, not your target. That's your real number, not the one in the SLA deck.
• Map your critical request path end to end and count the services in series. Calculate the composite availability using their individual numbers, not the number on your top-level dashboard.
• Write down your current SLO and convert it into an error budget in minutes for this month. If nobody on your team can tell you how much budget is left right now, you don't have an error budget — you have a slogan.
• Pick one dependency on that critical path with no fallback and no circuit breaker. Design the cheapest possible degradation path for it — stale cache, queued retry, reduced feature — before you design anything else this quarter.
• Take one recent incident and time how long it took from "detected" to "understood" versus "understood" to "fixed." Most teams find their MTTD, not their MTTR, is the actual bottleneck.

Key takeaways

• Availability, uptime, and reliability are three different measurements. Optimizing for the wrong one produces a system that looks fine on a dashboard and fails its users anyway.
• A = MTBF / (MTBF + MTTR) gives you two levers. MTTR is almost always the cheaper, faster one to pull, and it buys the same availability gain per unit of improvement as MTBF.
• Each additional 9 costs roughly an order of magnitude more than the last in infrastructure, process, and human cost. Past four nines, for most teams, that trade stops paying for itself.
• Availability multiplies across dependencies in series. Your architecture's dependency graph caps your achievable availability before your operational effort gets a vote.
• Error budgets convert "don't break it" into a spendable number. That's the mechanism that actually aligns engineering and product on risk, not a policy memo.
• The architecture that survives isn't the one that wins the design review. It's the one your on-call can recover at 3am without calling the person who built it.

Your next step

If you want a second set of eyes on where your architecture's real availability ceiling is — not the number on the dashboard, the one your dependency graph actually allows — bring it to a mentorship or architecture review conversation. No pitch, no sales process. Just the same question I ask my own designs now: can the on-call fix this at 3am without you.

Frequently asked questions

What's the difference between availability and uptime?

Uptime is whether the process is running. Availability is whether the system is usable by someone who needs it right now, which accounts for latency and partial failure. A system can have 99.9% uptime and still be functionally unavailable if every request is timing out or taking 30 seconds to return.

How do you calculate availability?

Two common ways: time-based, A = uptime / (uptime + downtime), which is a retrospective measurement of what happened; and component-based, A = MTBF / (MTBF + MTTR), which splits availability into how often you fail and how fast you recover — the more useful formula for deciding where to invest.

Why does each additional "nine" of availability cost so much more?

Because the infrastructure, testing, and operational discipline required scales roughly by an order of magnitude at each tier — from basic redundancy, to multi-AZ failover, to multi-region active-active with fully automated recovery and a 24/7 team large enough to sustain it without burning out. The cost isn't linear; the reliability requirement is.

What is an error budget, and how do you calculate it?

An error budget is the amount of failure your SLO permits over a time window: (1 − SLO) × time window. At a 99.9% SLO over 30 days, that's 43.2 minutes. It converts an abstract reliability target into a spendable number both engineering and product can use to decide whether shipping a risky change this week is acceptable.

Why does availability get worse when you add more services, even if each one is reliable?

Because availability multiplies across dependencies in series. Five services at 99.9% each combine to roughly 99.5% composite availability — worse than any single component, because each additional dependency on the critical path is a multiplicative tax, not an additive risk. Redundant, parallel paths are the only way to claw that back.

Should every team aim for five nines?

No, and most shouldn't try. Five nines allows about 26 seconds of downtime a month, which is too short for any human-in-the-loop recovery process. It requires fully automated failover and detection, multi-region infrastructure, and a 24/7 operating model. For most products, the business impact between four nines and five nines doesn't justify that cost — the better investment is almost always lowering MTTR.