What is SLO?

A useful SLO is derived from what users need rather than from what the system currently achieves. The starting question is at what point users notice and care, and the target is set just above that threshold.

The measurement window matters as much as the number. A 99.9% target over a rolling 30-day window behaves differently from the same target over a calendar month, since the rolling window avoids the reset effect where a bad month ends and everyone starts fresh.

The SLO is where reliability becomes a decision-making tool rather than a sentiment.

• Defines enough: reliability work has a stopping point instead of being open-ended.
• Generates the error budget: for percentage-based targets, the gap to 100% is the allowable failure.
• Resolves conflict: ship versus stabilize becomes a question about budget remaining.
• Focuses alerting: pages can fire on SLO threat rather than on every anomaly.

Setting the SLO to match current performance is a frequent error. It guarantees the target is met and provides little information, since the objective was reverse-engineered from the outcome.

Targets that are too strict are equally unhelpful. An SLO the architecture cannot support is violated constantly, the error budget stays exhausted, and the team learns to ignore it. An SLO nobody acts on can cost more than none, because it consumes the credibility a realistic one would need.

An SLO is a measurable service-level target. An SLA is an explicit or implicit agreement with users that includes consequences associated with meeting or missing the service levels it contains.

Organizations often use an internal SLO that is stricter than a contractual or externally communicated target so that engineering teams have time to respond before triggering customer-facing consequences. This is a useful practice, not a requirement of the definitions.