Service Level Objectives

Service level objectives

An objective turns reliability from an argument into a number. Its real value is the error budget: the amount of unreliability you have decided is acceptable, which converts "should we ship or stabilise" into a question with an answer.

Method

1. Measure what users experience. Successful requests and acceptable latency at the edge, not internal component health, since a system can be green everywhere and broken for users.
2. Set the target below one hundred percent deliberately. Perfect reliability costs more than it returns, and the gap is the budget you spend on change.
3. Derive the budget and track its consumption. Budget remaining this period is the operational number, and it makes the trade visible (see error-budget-policy).
4. Agree the policy before you need it. What happens when the budget is exhausted, decided in calm conditions rather than mid-incident.
5. Keep the objective count small. A handful of user-facing objectives is actionable; dozens of component targets are noise.
6. Measure over a rolling window. Calendar-month resets create incentives to gamble at month end.
7. Revisit when reality diverges. An objective never breached is too loose and one always breached is not a target (see alerting-design).

Boundaries

Objectives describe reliability and do not deliver it. A target agreed without the investment to meet it is a fiction. Some failures are so severe that budget accounting is irrelevant and the response is immediate regardless (see incident-severity-levels).