Reliability Economics

Every reliability conversation eventually produces a number that sounds like a technical specification — "99.9% availability," "99.99%," occasionally the aspirational "99.999%" — and most of the time that number was chosen by instinct, by whatever a competitor advertises, or by rounding up from whatever the last incident review made everyone nervous about. None of those are wrong exactly, but none of them are an argument either. The SRE discipline treats target availability as the output of a calculation, not an input you pick first: quantify what a minute of downtime actually costs the business, quantify what a minute of avoided downtime costs to buy, and the target that falls out of comparing the two is one you can defend in a budget review instead of merely assert in a slide. This page works that calculation end to end — from "99.999%" as a phrase, to an annual downtime-minutes budget as a number, to a dollar figure attached to every one of those minutes.

Reliability is a cost decision, not an aspiration

☺ Like you're 10: Nobody buys the biggest lock money can buy for a garden shed — the size of the lock should match what's actually inside. The SLO target works exactly the same way.

Say the sentence "we should target five nines" out loud in a planning meeting and it sounds like ambition. Say the sentence "we should spend roughly $380,000 a year buying back the last 473 minutes of annual downtime, on a service where a minute of downtime costs us about $300" and it sounds like a decision someone can actually evaluate — because it is one. Reliability economics isn't a separate discipline bolted onto SRE; it's the argument that was supposed to happen before the SLO number got written down, made explicit instead of assumed. Google's own Site Reliability Engineering book states the underlying claim almost in passing, in a line worth taking more literally than it usually gets taken: 100% reliability is the wrong target for almost any system, because the cost of the last increment of reliability rises without bound while the value a user gets from it approaches zero.

Two curves are doing all the work in that sentence, and this page is mostly about making both of them concrete instead of hand-wavy. The cost of downtime — lost revenue while the system is unavailable, penalties owed under contract, and the harder, slower cost of customers who don't come back — falls as your target availability rises, because there's simply less downtime happening. The cost of buying that reliability — redundant infrastructure, additional engineering headcount, more disciplined testing and rollout process, an expanded on-call rotation — rises as your target rises, and it rises faster than linearly, because each additional nine typically demands a qualitatively different engineering investment, not just a bigger version of the last one. Somewhere between those two curves sits a point where the total is lowest. That point, not a marketing slogan about nines, is the economically correct SLO target.

The three costs of downtime: revenue, contracts, and trust

☺ Like you're 10: When the system goes down, three different wallets take a hit — the one that's easy to see (money not made right now), the one written into a contract (a promised refund), and the one that's almost invisible until months later (customers who quietly stop coming back).

"The cost of downtime" is not one number; it's a sum of three, with wildly different degrees of measurability and, usually, wildly different magnitudes.

Direct, measurable: lost revenue

For any business where the system being up is the business — checkout, booking, trading, ad serving — the most legible cost of downtime is straightforward in concept and genuinely tricky in practice: revenue that would have happened during the outage and didn't. The concept is one division (annual revenue over minutes in a year); getting a number that means something takes the two refinements worked through later on this page. The short version: most businesses don't lose 100% of the revenue an outage window would otherwise have produced — some of it is deferred rather than destroyed — and exactly how much of each depends on your specific customers, your specific competitors, and how urgent the thing they were trying to do actually was.

Contractual: SLA credits and penalties

If you sell the service under a Service Level Agreement, missing your committed availability usually triggers a specific, contractually-defined consequence — most commonly a service credit against future billing, occasionally a cash penalty or a termination right for repeated or severe breaches. This is the one cost component on this page that requires no estimation at all: it's written down, in the contract, as an exact formula. Which makes it tempting to treat as the cost of downtime — a temptation this page argues against directly below, because it's almost always an order of magnitude too small.

Harder to measure, often larger: trust and churn

The cost that rarely makes it into a spreadsheet is usually the largest one: some fraction of the customers affected by a bad-enough outage quietly trust you less, and some fraction of that fraction leaves — not immediately, not with an angry email citing the incident, just a slightly elevated churn rate in the affected cohort, showing up in a retention report weeks or months later with no obvious causal thread back to a specific Tuesday afternoon. This cost is real, frequently larger than the direct revenue loss and the SLA credit combined, and almost never linear in outage minutes — a crisp, well-communicated 12-minute blip most users never notice erodes trust by roughly nothing, while a 90-minute outage during your highest-visibility event of the year can measurably move a retention curve. Estimating it honestly, rather than ignoring it because it's hard, is the subject of the worked example later on this page.

Why an SLA credit is not the cost of downtime

☺ Like you're 10: A refund coupon for a bad meal isn't the same number as what that meal actually cost you — the lost afternoon, the friend you were trying to impress. The coupon is just the amount the restaurant pre-agreed to cap its own liability at.

Cloud-provider SLAs are the clearest illustration, because everyone reading this page has one to check against. AWS, Google Cloud, and Azure all publish availability commitments for their major services, and the shape is nearly universal across all three: fall below a stated monthly availability threshold and you receive a service credit, commonly on the order of 10% of that month's charges for a moderate breach, rising to 25-30% for a severe one — figures worth checking against the current published SLA for the specific service you're relying on, since exact tiers and thresholds vary by product and change over time. Two structural facts about that credit matter far more than the exact percentage. First, it's capped: even a total, month-long outage of a given service typically caps your credit at some fraction — often 100% — of what you paid for that specific service that month, never at what the outage actually cost your business downstream. Second, it's a liability ceiling the vendor chose, not a number derived from your damage — it exists to bound the vendor's own exposure, set by the vendor's legal and finance teams optimizing for the vendor's risk, not yours.

The same structure repeats one layer up when you're the one offering the SLA to your own customers: your credit schedule protects your balance sheet from unbounded liability, and it does that job well, but it was never designed to equal the true cost of the outage to the customer who experienced it, or to you, in lost trust and future revenue. Treating "what we owe under the SLA" as "what the outage cost" anchors your reliability-investment decision on a number that's almost always too small to justify the spend that would actually prevent the next one.

From a target percentage to an annual downtime budget

☺ Like you're 10: "99.99%" doesn't feel like a real amount of anything until you turn it into a number of minutes you're actually allowed to be broken each year — then it stops being an abstraction.

A target availability is a percentage; a downtime budget is that percentage converted into a concrete quantity of time, and the conversion is the same one-line arithmetic SLIs, SLOs & error budgets already introduced for a 30-day operating window — this page runs the identical formula over a full calendar year instead, because that's the window most cost-of-downtime and SLA-credit conversations actually happen in when you're presenting to finance or a customer, not the rolling window your team uses day to day for release decisions.

Annual downtime budget = (100% − target availability) × minutes in a year

365-day year = 365 × 24 × 60 = 525,600 minutes

Estimating your revenue-per-minute number

☺ Like you're 10: The naive answer — money in a year divided by minutes in a year — is a fine starting point and a genuinely wrong final answer, because not every minute of your year is worth the same amount.

The naive average, and why it's a starting point, not an answer

Take a concrete, if invented, example this page carries through to its conclusion: Acme Retail, an online apparel retailer, books $262.8M in annual online revenue. Divide by the 525,600 minutes in a year and the naive number is clean: $500 per minute, on average, across the whole year, every year. That number is real, and it is also almost useless on its own, for two separate reasons.

Refinement one: revenue isn't uniform across the day or the year

Traffic, and therefore revenue, concentrates. E-commerce sites commonly see revenue rates during evening peak hours or a marketing event run two to four times the daily average, while overnight-trough rates fall to a fraction of it — sometimes below a quarter of average. The practical consequence is uncomfortable but important: the same 30-minute outage can cost roughly ten times as much or as little, purely depending on when the clock started, which means a single blended average is the wrong number to multiply against any specific incident. The right number for comparing SLO targets is a distribution, not a point estimate — at minimum, separate average-traffic, peak-traffic, and trough-traffic per-minute rates, weighted by how outages are actually distributed across your own traffic pattern. A service more likely to fail under peak load, because that's when it's most stressed, should weight toward the peak number, not the average one.

Refinement two: not every dollar interrupted is a dollar gone

A user who can't check out right now doesn't necessarily represent a dollar permanently destroyed — some meaningful share of interrupted purchase intent is deferred rather than lost outright: the same user returns within hours or the next day and completes the same purchase once the site recovers, especially for considered purchases with no substitute readily at hand. The share that's genuinely, permanently lost rather than deferred depends on how substitutable your product is (a competitor one tab away captures intent you don't get back), how time-sensitive the purchase was (a flash sale or limited inventory converts "come back later" into "gone"), and how long the outage lasts. Model this as a loss factor between 0 (fully deferred, effectively no true loss) and 1 (fully lost) applied to the naive revenue rate — and, this part matters, don't guess at the number. Measure it, by comparing purchase-conversion in the days immediately following a past incident against a comparable non-incident baseline; the gap between "conversions dipped and never recovered" and "conversions dipped and then spiked back above baseline for a few days" is a direct, if noisy, read on your own actual loss factor.

Worked example: setting Acme Retail's checkout SLO from the economics

☺ Like you're 10: Put every number from the last three sections into one table for one real decision — should checkout target 99.9% or 99.99% — and let the arithmetic, not a gut feeling, pick the answer.

Acme's checkout service is under debate: should its SLO be 99.9% (three nines) or 99.99% (four nines)? Every input below is stated as an assumption, deliberately, so it's auditable rather than smuggled in — replace each one with your own measured numbers before trusting the conclusion for a real decision.

• Annual online revenue: $262.8M → naive average of $500/minute. (This worked example uses the average-traffic rate throughout for clarity; a full model would run Steps 2-4 separately for peak and trough traffic, per the refinement above.)
• Loss factor for an average-traffic checkout outage: 0.6 — 60% of interrupted purchase intent is genuinely lost, 40% deferred and eventually recaptured. Effective lost-revenue rate: $500 × 0.6 = $300/minute.
• External enterprise SLA already in force, independent of which internal target Acme picks: 99.5% monthly, with a credit of 10% of that month's contract value per full percentage point of shortfall, prorated. B2B contract book: $2M/month.
• Historical SLA-breach frequency: one month in the last three years dipped to 99.2% monthly availability — 0.3 points under the 99.5% commitment.
• Trust/churn cost of a severe incident, from Acme's own postmortem-linked cohort analysis: one 90-minute checkout outage in the last two years was followed by a measurable ≈1.5 percentage-point increase in 90-day churn among the roughly 50,000 customers who tried to check out during it. Acme's estimated customer LTV: $1,200.

Step 1 — the downtime budget itself. 99.9% allows 525.6 minutes/year; 99.99% allows 52.56 minutes/year. Moving from three nines to four buys back 473.04 minutes/year of downtime — roughly a 90% cut.

Step 2 — direct revenue. 473.04 minutes × $300/minute effective lost-revenue rate ≈ $141,912/year in avoided direct revenue loss, assuming — a real assumption, flagged deliberately — that the avoided minutes are distributed like an average minute rather than concentrated in peak traffic. In practice the extra nine disproportionately squeezes out long-tail incidents, which are more likely to straddle a peak window, so this figure is if anything conservative.

Step 3 — SLA credit, as an expected value. The bad month cost 10% × 0.3 points × $2M = $60,000 in credits, and it happened roughly once every three years. Treat that as a tail-risk cost rather than a guaranteed annual line item: expected annual SLA-credit cost ≈ $60,000 ÷ 3 ≈ $20,000/year. Whether moving to 99.99% meaningfully reduces the probability of that bad month recurring is itself worth modeling explicitly rather than assumed — this example assumes it does, since a tighter internal target directly widens the margin above the external SLA commitment.

Step 4 — trust and churn, as an expected value. The one severe incident on record cost roughly 50,000 × 1.5% × $1,200 ≈ $900,000 in attributable churn. If a 99.99% target specifically prevents an incident of that severity and duration roughly once every 2.5 years — again a load-bearing, explicitly-stated assumption, because this is a threshold effect rather than a linear one — the expected annual value is $900,000 ÷ 2.5 ≈ $360,000/year.

Step 5 — total, and the decision. $141,912 + $20,000 + $360,000 ≈ $522,000/year in expected avoided cost from buying the extra nine. Against that, price the engineering side of the ledger — the next section works that out in general, but for Acme's checkout service specifically: roughly one additional senior SRE's fully-loaded cost (≈$300K/year) plus incremental standby-infrastructure spend (≈$80K/year) ≈ $380K/year ongoing. $522K in expected benefit against $380K in ongoing cost is a net positive of roughly $142K/year — for this specific, revenue-bearing, trust-sensitive service, the fourth nine is worth buying.

Run the identical five steps against a low-traffic internal admin tool with no SLA and no customer-visible trust exposure, and the direct-revenue and trust terms both collapse toward zero — the same $380K investment stops being justified, and 99.9% remains the correct target for that service. That contrast is the entire argument of this page in miniature: target availability is not a company-wide slogan, it's a per-service answer to a per-service calculation.

The marginal cost of buying a nine

☺ Like you're 10: Getting from "occasionally broken" to "rarely broken" is a different, bigger job than getting from "rarely broken" to "almost never broken" — each step up costs more than the last, and buys a different kind of engineering, not just more of the same.

The benefit side of the calculation (the three sections above) gets most of the attention because it produces the more dramatic numbers, but the cost side is just as real and considerably less linear than intuition suggests. Moving a typical service through the nines tends to require qualitatively different engineering investment at each step, not simply "more of the same, harder":

• ~99% → ~99.9% usually means fixing your worst, most obvious single points of failure, adding basic health checks and restart automation, and standing up alerting that actually pages a human — foundational hygiene most services can reach with modest, one-time effort.
• ~99.9% → ~99.99% typically requires real redundancy across failure domains — multi-AZ architecture, automated failover that's actually been tested, load shedding and graceful degradation (see reliability patterns) — and enough rigor in rollout process, canarying, and staged deploys that a bad change gets caught before it becomes a long incident rather than after.
• ~99.99% → ~99.999% generally requires multi-region active-active or active-passive architecture, materially more disciplined change management, a dedicated team whose job is reliability rather than a shared responsibility, and a standing practice of proving the resilience investment actually works under real failure rather than assuming it does — precisely what chaos engineering exists to verify, deliberately and on a schedule, instead of finding out during a real incident.

Each step doesn't just cost more in absolute terms — it costs more per minute of downtime avoided, because the easy, cheap fixes get used up first. This is the accelerating curve on the right side of the schematic above, and it's the reason five nines is the correct target for vanishingly few systems: not because it's technically unreachable — it isn't, given enough money and organizational discipline — but because for almost every business the incremental engineering spend required to close that last gap exceeds what the last few minutes of avoided downtime are actually worth. Google's own SRE book makes a version of this argument concretely: once you've measured how reliable the network path to a typical mobile client actually is — often well short of 99.99% on its own, for reasons entirely outside your control — spending to push your backend meaningfully past that ceiling buys reliability improvements most users structurally cannot perceive, because their own connection is already the weaker link. Reliability beyond what a user can notice, or what the business case can justify, isn't diligence; it's an unbudgeted subsidy from engineering time to a number nobody downstream is actually spending against.

The scale of what's genuinely at stake when this reasoning gets skipped shows up starkly in public incidents. The February 2017 AWS S3 outage in us-east-1 lasted several hours and, per widely-circulated third-party estimates from the time — treat the precise figure as illustrative and contested rather than authoritative, and verify current sourcing before repeating it — was reported to have cost S&P 500 companies collectively on the order of hundreds of millions of dollars for the incident window alone. That's a number large enough that even a modest, well-reasoned investment in multi-region resilience for the businesses most exposed to it would very likely have cleared the same cost-benefit bar this page just worked through for Acme's checkout service, many times over. See the 2017 AWS S3 outage for the technical postmortem; the economic lesson underneath it is simply this page's calculation, run at a much larger scale.

Where this leaves your SLO conversation

☺ Like you're 10: Next time someone says "we should be more reliable," you now have the two follow-up questions that turn a feeling into a decision: how much does a minute of broken actually cost us, and how much does the next minute of fixed actually cost to buy?

Everything on this page collapses into two follow-up questions worth asking every time a target-availability conversation starts from a slogan instead of a number: what does a minute of downtime cost this specific service, across revenue, contract, and trust — and what does the next increment of reliability cost to buy for this specific service? SLIs, SLOs & error budgets already told you the right SLO is the loosest one users won't notice you missing; this page is the argument for how you actually locate that line instead of guessing at it. The same reasoning generalizes past availability targets to the RPO and RTO decisions in disaster recovery & business continuity, and to the capacity headroom you buy in capacity planning & performance — both are, underneath, the identical question of how much a specific kind of insurance is worth against a specific, priced kind of loss. The right place to have this conversation formally, before it becomes an argument during an incident, is a service's production readiness review — the SLO target belongs in that document with its cost justification attached, not chosen afterward to match whatever number the launch deck already promised. For a real organization that built exactly this reasoning into a durable, enforced policy rather than a one-time slide, see Google & the error-budget policy.