What is SLO?

#How SLOs are set

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.

#Why SLOs matter

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.

#Limits and common mistakes

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.

#SLO vs SLA

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.

#Key takeaways

• An SLO is a target value or range for a service level measured by an SLI; it may be used internally or communicated externally.
• For percentage-based SLOs, the gap between the target and 100% can define an error budget.
• Setting the SLO to match current performance produces a target that carries little information.
• An unrealistic SLO tends to get ignored, which can cost more than having no SLO at all.

#Frequently asked

How do you pick the right SLO value?

Find where users start to notice and care, then set the target just above it. Support tickets and abandonment data are better inputs than intuition.

What happens when an SLO is missed?

Whatever policy the team has defined in advance, commonly redirecting engineering effort to reliability and pausing non-essential releases until the budget recovers.

Should every service have an SLO?

Every service with users who care about its behavior. Internal batch jobs with no latency sensitivity often do not need one, and adding them can dilute attention.

#Sources

• Google SRE: service level objectives