Teams usually reach for service level objectives after an argument. Product wants faster features, operations wants fewer pages, and nobody can say what “reliable enough” means. SLOs exist to turn that argument into a number both sides agreed to in advance.

The vocabulary sounds heavier than the idea. A service level indicator (SLI) is a measurement of how your service behaves from a user’s point of view. A service level objective (SLO) is the target you set for that measurement over a time window. The error budget is whatever the target allows you to get wrong.

Start With User Experience, Not Server Health

CPU usage is not an SLI. Users do not care about CPU. They care whether requests succeed and whether they are fast enough. Good SLIs describe outcomes:

• Availability: the proportion of valid requests that succeed.
• Latency: the proportion of requests served faster than a threshold you choose.
• Correctness or freshness: for data pipelines, the proportion of results that are right or recent enough.
• Durability or completeness: for storage or batch work, whether data survived or jobs finished.

A useful form is “good events divided by valid events”. It keeps the arithmetic simple and makes the budget easy to compute. Decide carefully what counts as valid. Requests rejected because the caller sent garbage generally should not count against you.

For latency, prefer a threshold on a proportion (“most requests under this time”) over an average. Averages hide the slow tail that unhappy users actually experience.

Where to Measure

Measure as close to the user as you can reasonably get. The load balancer or ingress is often a good compromise because it sees real requests and real responses. Measuring only inside the application misses failures where the app never received the request. Synthetic probes from outside add a useful cross-check, though they only represent the paths you probe.

Pick very few SLIs per service. Two or three that capture what matters beat a dozen nobody looks at. Start with the critical user journeys, such as signing in or completing a purchase, rather than every endpoint.

Setting the Target

This is where teams stumble by aiming for perfection. A target of 100 percent is not achievable and it is not desirable, because the cost of each extra increment rises steeply while users often cannot perceive the difference. Also, dependencies, networks and user devices will not be that reliable either.

A practical method:

1. Look at your recent history for the SLI. What have you actually been delivering?
2. Ask what level users would notice and complain about.
3. Set the objective somewhere between those, slightly below what you reliably achieve now, so it is credible.
4. Review it after a while and tighten or loosen it.

Do not copy a target from another company. Their users, architecture and tolerance differ from yours.

Error Budgets in Plain Terms

If your SLO is a target for success over a window, the budget is the allowed failure. Take a hypothetical SLO where most requests must succeed over a rolling month. The remaining slice is the budget. Every failed request, every outage minute, spends some of it.

The budget turns reliability into a shared resource rather than a moral position. While budget remains, the team can take risks: ship faster, run experiments, do risky migrations. When budget is nearly gone, the team shifts effort toward stability work. That policy needs to be written down and agreed by product and engineering, otherwise the numbers are decorative.

Turning It Into Alerts

SLOs should shape paging. Instead of alerting on every blip, alert on how fast the budget is burning. A sudden severe failure that would exhaust the budget within hours deserves an immediate page. A slow leak that would exhaust it over weeks deserves a ticket, not a 3 a.m. wake-up.

This connects directly to alert fatigue. Page only for things that threaten the objective, and route lesser signals elsewhere. Your monitoring tool’s current documentation will describe how to express burn-rate alerts.

Example SLO Worksheet

Item	Example entry	Notes
Service	Checkout API	One owner named
User journey	Customer completes an order	Described in plain words
SLI	Valid order requests returning success, divided by valid order requests	Measured at the load balancer
Latency SLI	Share of order requests completing under an agreed threshold	Threshold chosen from user expectations
Window	Rolling month	Pick one and keep it
Objective	Set from history, below current typical performance	Revisit regularly
Budget policy	Slow risky releases when budget is nearly spent	Signed by product and engineering
Alerting	Burn-rate based page plus ticket for slow burn	Replaces some raw alerts

A Realistic Example

A small team runs an API that has had several noisy incidents. They pick one user journey, order placement, and define the availability SLI at the load balancer, excluding client-error responses. They check the previous quarter’s data, find they have been reliably good but with two bad days, and set an objective just below their typical performance.

For the first month they simply watch. Midway, a bad deploy burns a large share of the budget in an afternoon. At review, product and engineering agree to a rule: when more than half the budget is gone, risky changes wait. The following month they tighten their deploy checks, and fewer pages fire, because alerts now track budget burn instead of every error spike.

The numbers were not impressive. The agreement was.

Frequently Asked Questions

What is the difference between an SLA and an SLO? An SLA is a contractual commitment, often with penalties. An SLO is an internal target, normally stricter than any SLA so you have warning before breaching it.

How many SLOs should a service have? Few. Two or three tied to key user journeys. More than that dilutes attention and creates maintenance burden.

What if we have no historical data? Start measuring first and set a provisional objective after a few weeks of observation. A rough target you review beats waiting for perfect data.

Do internal services need SLOs? Often yes, because their consumers are other teams. Treat those teams as your users and measure what they depend on.

What happens when the budget runs out? Whatever your written policy says. Typically feature releases slow and reliability work takes priority until the service recovers. The value is that the response was agreed beforehand.

Next Step

Choose one service and one user journey. Write its SLI as a good-over-valid ratio, pull the last few weeks of data, and draft a provisional objective. Put it in front of the product owner with one question: would you accept losing that much?