Playbook
How to Set SLOs and Error Budgets
Setting SLOs and error budgets means choosing the reliability indicators that matter to users, setting realistic targets on them, and turning the gap to perfection into a budget that governs how much risk you take.
SLOs make reliability a deliberate decision rather than an absolute. You pick indicators that reflect user experience, set targets you can actually meet, and use the error budget, the allowed unreliability, to decide when to ship and when to stabilise. The discipline is choosing indicators that matter and targets you will honour.
Choose SLIs that reflect the user
A good SLI moves when users are actually affected, usually a ratio of good events to total events: successful requests over all requests, or requests under a latency threshold. Avoid convenient internal metrics that look healthy while users suffer. Pick a small number that genuinely represents the experience.
Set targets you will honour, and act on the budget
An SLO target (say 99.9% over 30 days) should be achievable and meaningful; too strict and you will ignore it, too loose and it protects nothing. The error budget is one minus the SLO, and it only matters if you act on it: healthy budget means you can take risks and ship, a nearly-exhausted budget means slow down and prioritise reliability. Alert on the burn rate, not just the raw number.
- Pick your SLIs. Choose a few indicators that reflect real user experience, as good-over-total ratios.
- Set realistic SLO targets. Achievable and meaningful, over a defined window.
- Derive the error budget. One minus the SLO; the unreliability you are allowed.
- Write an error-budget policy. Agree what happens when the budget runs low, typically a freeze on risky changes.
- Alert on burn rate. Page when you are spending the budget too fast, not just when it is gone.
Common mistakes when setting SLOs
The most common failure is setting SLOs the team will not honour. A 99.99% target sounds ambitious in a planning meeting and becomes decorative in a real incident review; nobody freezes deploys to protect a target nobody believes in. The second is picking too many SLOs. Three well-chosen SLIs per service is genuinely useful; twelve is a compliance exercise. The third is measuring SLIs against internal metrics that look healthy while users suffer. If the SLI is 'CPU under 80%' the team is measuring itself, not the user experience.
How to know the SLOs are working
The SLO discipline is working when three things happen. Product-and-engineering conversations reference the error budget as a real constraint (not a chart nobody looks at). Deploys are actually paused when the budget burns fast. And incidents get prioritised by SLO impact, not by whoever raised the loudest voice. If none of those happen after a quarter of running the SLO programme, something is wrong: usually the targets are unrealistic, or the error-budget policy has no teeth.
How Opstral uses SLOs
Opstral computes SLIs from the request-level telemetry it ingests and can prioritise incidents by their impact on your SLOs, so Sentinel AI acts first where an error budget is burning fastest, tying autonomous resolution directly to the reliability targets you set.
Frequently asked questions
How do I choose an SLO target?
Base it on user expectations and the cost of reliability, and pick a target you will actually honour. Common choices are 99.9% or 99.95%, leaving an error budget that allows shipping.
What is an error-budget policy?
An agreed rule for what happens as the budget depletes, typically freezing risky changes and prioritising reliability work until it recovers.
How do we get product buy-in for the error-budget policy?
By framing it as a shared decision, not an engineering constraint. The error budget is really a joint agreement between product and engineering about acceptable unreliability. When product understands that the alternative to a paused deploy is a real customer impact, the conversation gets easier. The teams where this fails are usually the ones where engineering set the SLO in isolation and then presented product with the consequence.
How does autonomous resolution interact with error budgets?
Directly and beneficially. Autonomous resolution reduces the frequency and duration of unreliability incidents, which slows the burn rate on the error budget. That translates to more room for the engineering team to ship. Teams that adopt autonomous resolution alongside a mature SLO practice typically see error-budget health improve without changing the underlying SLO targets.