SLIs, SLOs & Error Budgets
You'll learn to
- -Compute an error budget from an SLO
SLI, SLO, SLA
- -SLI (Service Level Indicator): the actual measured number, e.g. "99.87% of requests succeeded last month."
- -SLO (Service Level Objective): the internal target you're designing and operating toward, e.g. "99.9% success rate."
- -SLA (Service Level Agreement): an external, often contractual promise with real consequences (refunds, penalties) if missed.
Error Budgets
If your SLO is 99.9% uptime, you have an explicit budget of about 43 minutes of allowed downtime per month. Instead of treating every second of downtime as an unplanned failure, teams spend that budget deliberately (on risky deployments, on experiments, on maintenance windows) and only slow down shipping once the budget for the month is exhausted.
This reframes reliability as a resource you allocate, not an absolute you chase. 100% uptime isn't just unrealistic: deliberately pursuing it means you'd never be able to ship anything new.
Your team just burned through this month's entire error budget in the first week. What should actually change?
"Nothing yet: there's still three weeks left to stay under budget overall."
"The budget being spent early is exactly the signal it's designed to produce: freeze risky deployments and non-essential changes for the rest of the month, and put the team's attention on reliability work instead of new features until the budget resets. Treating the budget as just an end-of-month number to hit, rather than a real-time throttle on risk-taking, defeats the entire point of having one."