Most reliability arguments are really arguments about risk tolerance held by people who never agreed on a number. One engineer wants to freeze deploys; another wants to ship. An error budget ends the argument by turning reliability into an accounting balance: you have a fixed amount of unreliability to spend, everyone can see the balance, and the decision to ship or stop becomes arithmetic rather than opinion. This framework is the ledger.
The three layers
Reliability targets stack in three layers, and confusing them is the most common source of error-budget mistakes.
| Layer | What it is | Who it is for | Consequence of a miss |
|---|---|---|---|
| SLI | The measured indicator (success rate, latency) | Engineering | None directly - it is just a number |
| SLO | The internal target for the SLI | The team | Spends the error budget |
| SLA | The external contract with a customer | The business | Owes a credit, per the SLA table |
The SLO is the one you manage day to day, and it must be tighter than the SLA. If you promise a customer 99.9 percent and target 99.9 percent internally, you have no buffer: the first bad month is a breach. Target 99.95 percent internally, and the gap becomes the margin that keeps a rough week from becoming a claimable credit.
Computing the budget
The budget is simply one minus the SLO, applied to the window. For a 30-day (43,200-minute) window:
| SLO | Downtime allowed / 30 days | Practical read |
|---|---|---|
| 99.0% | 432 min (7.2 hr) | Generous - fine for internal tools |
| 99.9% | 43.2 min | The common default for customer services |
| 99.95% | 21.6 min | Tight - needs tested multi-AZ failover |
| 99.99% | 4.3 min | Very tight - needs multi-region and automation |
Notice how quickly the budget collapses. Moving from 99.9 to 99.99 percent removes 90 percent of your allowance, which is why every extra nine costs roughly an order of magnitude more in architecture. Pick the loosest SLO your customers will accept, because you will pay for the difference in failover engineering.
Spending the budget: burn rate
A static budget tells you the total; burn rate tells you how fast you are spending it. A burn rate of 1 means you will exhaust the budget precisely at the end of the window. A burn rate of 2 means you will run out in half the window. The insight from the Google SRE workbook is to alert on burn rate over multiple windows at once, so a single blip does not page anyone but a genuine degradation does.
Fast burn versus slow burn
- Fast burn (for example, 14.4x over a 1-hour window) means you would drain a 30-day budget in about two days at that pace. That is a page-a-human event.
- Slow burn (for example, 3x over a 6-hour window) is a quieter drip that will still ruin the month if ignored. That is a ticket, reviewed in business hours.
The two-window pattern (a long window to confirm the problem is real, a short window to confirm it is still happening) is what keeps error-budget alerting from becoming noise. Tune it once and it replaces a dozen threshold alerts.
Using the budget as a policy
The budget is only useful if spending it changes behavior. A workable policy has three states:
- Budget healthy (over 50 percent remaining): ship freely. Reliability is not the constraint.
- Budget low (under 50 percent): new risky changes need a second reviewer; error-reducing work moves up the backlog.
- Budget exhausted: a feature freeze on the affected service until the budget recovers, with the freeze lifting automatically as the window rolls forward.
The freeze is the part people resist and the part that matters. It converts reliability from a value everyone claims to hold into a cost the whole team feels, which is the only thing that makes reliability work compete fairly with features.
Where the framework connects
Error budgets do not stand alone. The incident severity classification tells you which incidents are large enough to charge against the budget; the cloud reliability maturity model tells you whether your organization is mature enough to hold a budget at all (you need Level 3 detection before the numbers are trustworthy). When an incident breaches the external SLA rather than just the internal SLO, it becomes a recovery question: our research on outage duration and the methodology behind the corpus show how often those breaches go unclaimed, and cloud-credits.com covers the mechanics of collecting them. To see how real events would score against a budget, browse the incident data or the provider-specific record at awsdown.com.
The error budget is the single most portable idea in reliability engineering: it gives a finance-literate organization a number it already knows how to reason about. Our monitoring sponsor, Next Signal, watches provider status feeds and flags the breaches that spend your budget without your team noticing, so the ledger reflects reality rather than only the incidents you happened to catch.