We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Reliability Resilience
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Reliability Resilience
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Before error budgets, every company had the same fight. Developers wanted to ship features. Ops wanted to avoid outages. Both sides were right. Both sides had irreconcilable goals. The argument escalated in every sprint planning meeting, and whoever had the louder voice that week won.
Google SRE solved this in 2003 by inventing the error budget. The logic is simple. If your SLO is 99.9% success rate, that means you are allowed 0.1% errors per month. For a service handling 10 million requests per day, that is 10,000 errors per day, or about 43 minutes of total downtime per month. That 0.1% is your error budget. It is real, measurable, and finite.
When the budget has plenty left, developers ship features as fast as they want. Nobody blocks a deploy because "it might cause an outage." When the budget is getting tight, risky changes need SRE review. When the budget is spent, feature deployments freeze and the entire team works on reliability until the budget recovers. The budget is the tiebreaker. There is no argument because the math settles it.
This is the most important concept in SRE. Everything else, burn rate alerting, release gating, capacity planning, SLO engineering, flows from the error budget. It turns "reliability matters" from an opinion into a mechanical constraint that both developers and SREs respect because neither side gets to override the number.
The error budget is derived from the SLO. Nothing else.
| SLO | Error Budget (monthly) | Downtime Equivalent | Who Actually Needs This |
|---|---|---|---|
| 99% | 1% = 432 minutes | 7 hours 12 minutes | Internal tools, dev environments |
| 99.5% | 0.5% = 216 minutes | 3 hours 36 minutes | Non-critical user-facing services |
| 99.9% | 0.1% = 43 minutes | 43 minutes | Standard user-facing services |
| 99.95% | 0.05% = 21 minutes | 21 minutes | Payment processing, auth |
| 99.99% | 0.01% = 4.3 minutes | 4 minutes 18 seconds | Critical infrastructure (, CDN) |
The cost of each additional nine is roughly 10x the engineering investment. Going from 99.9% to 99.99% does not mean "try a little harder." It means dedicated on-call rotations, redundant infrastructure across regions, automated failover, and zero-downtime deployment pipelines. Most internet services do not need 99.99%, and overcommitting to a target you cannot afford wastes engineering effort that could be spent on features users actually want.
The SLO choice is the single most important decision in the entire error budget system. Set it too high and the budget is impossibly tight, every minor blip triggers a freeze, and developers lose faith in the system. Set it too low and the budget never runs out, nobody cares about reliability, and real outages go unfixed. The right SLO reflects what your users actually tolerate, measured by complaints, churn, and support tickets, not by what looks good in a slide deck.