Loading
An SLO that lives in a slide deck instead of your alerting pipeline isn't a reliability practice. It's a New Year's resolution.
Most teams that say they have SLOs actually have a target latency number written in a wiki page nobody has opened since the quarter it was created. That's not a criticism — defining a meaningful service-level objective is genuinely hard, and connecting it to a system that can act on it in real time is harder still. But the gap between 'we have an SLO' and 'our SLO changes what we do on a Tuesday afternoon' is where most of the value lives.
A target like '99.9% availability' is easy to state and almost useless on its own. What makes it actionable is the error budget it implies — in this case, about 43 minutes of downtime per month — and a policy for what happens when that budget is spent. Without the budget and the policy, the target is just a number teams quote in postmortems and otherwise ignore.
The teams that get real value from SLOs treat the error budget as a shared resource the whole team manages actively, not a lagging indicator reviewed after the fact. When the budget is healthy, ship faster and take more risk. When it's nearly exhausted, the default shifts toward stability work — and that shift should be visible and automatic, not something that requires a meeting to decide.
An SLO dashboard nobody looks at doesn't change behavior. The signal needs to show up where engineers are already working — in the deploy pipeline, in the on-call tool, in the same channel where incidents get discussed. A fast error budget burn should be exactly as visible, and exactly as actionable, as a failing test.
None of this requires exotic tooling. It requires treating the SLO as an operational input rather than a reporting artifact — something the system checks continuously, not something a human remembers to check before a quarterly review.