How to Set SLOs and Error Budgets

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.

1. Pick your SLIs. Choose a few indicators that reflect real user experience, as good-over-total ratios.
2. Set realistic SLO targets. Achievable and meaningful, over a defined window.
3. Derive the error budget. One minus the SLO; the unreliability you are allowed.
4. Write an error-budget policy. Agree what happens when the budget runs low, typically a freeze on risky changes.
5. Alert on burn rate. Page when you are spending the budget too fast, not just when it is gone.

How Ops Singularity uses SLOs

Ops Singularity 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.