How do SLOs and error budgets work?

Direct answer

What a strong answer covers

How it works

A service level indicator measures something users care about, such as the fraction of requests that succeed within 300 ms. The objective sets a target for it over a window, say 99.9 percent over 30 days, and the error budget is what remains: 0.1 percent of requests, or about 43 minutes of full outage a month. Alerts fire on burn rate, how fast the budget is being consumed, which catches both a sudden outage and a slow degradation. When budget remains, the team can take release risk; when it is exhausted, feature work yields to reliability work. The policy is agreed with product in advance so the trade-off is not renegotiated during each incident.

Example

The checkout API has an SLO of 99.95 percent of requests under 500 ms over 28 days. A fast-burn alert pages when the budget would be gone in under two hours; a slow-burn alert opens a ticket when it would be gone in three days. After a bad month consumed the budget by day 20, the team froze non-critical releases and spent the remaining sprint on the retry storm that had caused it.

Common mistakes

• Setting 100 percent or a target nobody measured the current value against.
• Alerting on the SLI threshold instead of burn rate and paging for every blip.
• Having no agreed policy for an exhausted budget so nothing changes when it runs out.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.