How to Define an SLO

List what users actually do with the service: log in, search, check out, submit a claim, load a dashboard. Pick the few journeys whose failure users notice and care about most. An SLO on a background job nobody waits for is rarely the place to start.

An SLI should answer whether an event went well for the user. Express it as a ratio: good events divided by valid events.

• Availability: proportion of valid requests that succeeded.
• Latency: proportion of valid requests completed faster than a threshold, for example 300 milliseconds.
• Freshness: proportion of reads returning data updated within a defined time.
• Correctness: proportion of results that were correct, where it can be checked.

Define valid carefully: excluding client errors caused by bad input is reasonable; excluding server errors because they were inconvenient is not.

Measure as close to the user as practical. Load balancer logs are better than application logs; synthetic or client-side measurements are better still for some journeys.

Before choosing a target, measure the SLI over several weeks. The baseline shows what the service actually delivers and exposes measurement problems, such as missing data or requests counted twice. Setting targets before measuring often produces objectives that are either permanently violated or trivially met. Check the baseline against user complaints and support tickets as well: periods of poor SLI performance should line up with periods when users noticed problems. If they do not, the SLI is measuring the wrong thing.

The target should be tight enough that meeting it means users are generally satisfied, and loose enough that the team is not permanently in breach. If users do not notice the difference between two targets, choose the looser one: every extra nine costs engineering effort and slows change.

Use a rolling window, commonly 28 or 30 days, so the SLO reflects recent experience rather than resetting at month boundaries. The error budget is simply one minus the target: at 99.9 percent over 30 days, roughly 43 minutes of full unavailability, or the equivalent share of failed requests.

This is the step most teams skip, and it is the one that makes an SLO matter. Agree in writing, with product owners, what happens as the budget is consumed. For example: alert on fast burn rates, prioritise reliability work when the budget is low, and pause risky releases when it is exhausted, with defined exceptions for security fixes. Without a policy, an SLO is a dashboard.

• Measuring components instead of journeys. CPU and host uptime say little about whether users succeeded.
• Averages for latency. Use a threshold-based ratio or percentiles; averages hide the slow requests users remember.
• Too many SLOs. Attention spreads thin and none of them drive decisions.
• Targets set by aspiration. An SLO that is always breached is ignored, and one that is never at risk teaches nothing.
• No owner. Every SLO needs a team responsible for it and for acting on its budget.
• Dependencies ignored. If a critical dependency cannot meet your target, your SLO cannot either; know the dependency's reliability before committing.

Alert on how fast the budget is being consumed, not on every error. A fast burn warrants a page; a slow burn warrants a ticket. Review each SLO after a quarter: did breaches match user complaints, did the team act on the policy, and is the SLI still measuring the right thing? Adjust, and document why.