Up, or reliable?
Bad: Count uptime
A wallet API answers 200 OK with a balance ten minutes stale. Still “up”.
Good: Count good ÷ valid events
Right, fast enough, as users felt it. Health checks aren’t valid events.
You run out of budget long before you owe credits.
Pay API: measured SLI 99.97%, SLO 99.95%, SLA 99.9% with credits. The gap from SLO to 100% is the error budget.
Why not 100%?
- Users can’t tell 99.99% from 99.999% on their phones
- It forbids change, behind roughly 70% of Google’s outages
- Each nine costs more than the last
- Overachieve, and teams assume you never fail
43.2
full-outage minutes per 30 days at 99.9%
Or 50,000 failed requests in 50 million. A 10-minute outage spends 23%; at a 9 pm peak, 69%.
Three incidents empty the budget by day 21. Without a consequence, it’s just a KPI.
What makes it bite
A signed policy: freeze all but P0 and security fixes until you’re back within SLO.
Burn rate: how fast you’re spending the budget
Error rate ÷ (1 − SLO). At 99.9%, 0.1% errors is 1× and lasts 30 days; a total outage is 1,000×, gone in 43 minutes.
Bad: Error rate over 0.1%
Pages on blips. Add for: 1h and an outage burns 139% first.
Good: Burn rate, two windows
Page when 1 hour and 5 minutes both top 14.4×. Clears after the fix.
Remember
Measure what users feel as good ÷ valid events. Spend 1 − SLO on change, freeze when it’s gone, and page on burn rate, not blips.