What are the risks of having no SLO?

Every service has a reliability target, even when nobody has written one down. If you did not choose it, someone else did. Users form expectations from what they experience. A manager may set a new expectation after an outage. A team may treat every failure as unacceptable because it is afraid of the next complaint.

Writing down what good enough means makes those expectations visible. A service level objective, or SLO, is a common way to do that.

An SLO rests on a service level indicator, or SLI: a measurement of some aspect of the service, such as the share of checkout attempts that succeed. The SLO sets a target for that measurement over a stated period: almost all checkout attempts should succeed over the review period. A service level agreement, or SLA, is a commitment to a customer that sets out what happens if an agreed service level is missed.

SLI: what you measure The share of checkout requests that succeed quickly. SLO: the target you set for it Almost all checkout requests succeed quickly, over a set period. SLA: the promise to customers A looser version of the target, with a consequence if it is broken. sets a target on promised with room to spare
The checkout ladder, from the measured share of successful checkouts, to the team's target, to a customer agreement and its consequences.

No agreed good enough

We have seen teams spend weeks, money and machines improving speed and reliability without knowing when enough is enough. The service gets faster, but the team may not know whether users notice or whether the time would have helped more elsewhere.

The opposite can happen too. Each blip becomes an urgent interruption because no one has agreed which failures need immediate attention. After an outage, demands for maximum reliability can clash with pressure to deliver features.

An SLO gives those discussions a shared reference. If checkout has consistently met an agreed target, the team can ask whether another reliability project is more valuable than the work it would displace. If it has missed the target, the team has evidence for examining the causes and changing priorities. The data changes the argument; it does not end it.

Users can't tell the difference Reliability perfect lower Cost and effort A target you chose
An illustrative curve showing the effort and cost of approaching perfect reliability rising beyond the point where further improvement is noticeable to users.

The gap between the target and perfect performance is often called an error budget. It describes how much measured failure fits within the target over the chosen period.

Alex Hidalgo argues that an exhausted budget should lead to a conversation about what happened and what to do next. A release freeze may be appropriate, but a fix may need to ship quickly, or the failure may have little to do with the planned change.

Which problems matter?

Monitoring can detect failures without an SLO. A failed health check, an error spike or a customer report can all tell you something is wrong. The harder question is which signal deserves an overnight page and which can wait for planned work.

An SLO tied to a user journey can help with that choice. If checkout failures are consuming the allowed margin quickly, someone may need to investigate now. A warning about an individual machine may matter less if users can still complete checkout and the team has time to investigate during working hours.

Time in the review period Error budget left full used up Slow burn: look at it in working hours Fast burn: page someone now
Two ways to use up an error budget. A slow burn can wait for working hours. A fast burn threatens the target soon and needs someone now.

Google's SRE Workbook recommends designing alerts around significant threats to the objective. A measurement can still miss a failing customer group, and some warnings reveal risks before users feel them.

A target on its own does not explain why a failure happened.

People build on actual behaviour

Users form expectations from the service they get. If a service has always responded quickly, another team may build a workflow that depends on that speed. A written target may say the service can be slower, but the dependency can exist anyway.

Google describes this problem with Chubby, an internal lock service that ran so reliably that other teams treated it as if it would never fail. When it did fail, which was rare, those teams were hurt. Hyrum's Law describes the broader pattern: users can depend on observable behaviour beyond what an interface promises.

Time Reliability The written target (SLO) What the service actually delivers Another team's system depends on this level Still within target, but the other team breaks
The service delivers more than its written target. Another team builds on that level, so a drop that is still within the target breaks them.

An SLO does not erase expectations created by past performance.

A note on customer promises

If the team watches only for an SLA breach, there may be little time to respond before the customer commitment is missed.

Google suggests setting a stricter internal objective than the customer-facing commitment. The gap gives the team room to notice a trend and act. A team can also watch the contract directly, with an earlier warning, and no separate internal SLO.

When an SLO makes things worse

An SLO has a cost. Someone must agree on what to measure, check that the measurement works, review the target and keep it relevant as the service changes. A small internal tool with a responsive owner may need only direct feedback and basic monitoring.

A poorly chosen indicator can also give false confidence. Imagine that the average response time across a service is inside its target. A frequently used fast endpoint can hide a slow checkout endpoint. The dashboard looks healthy while customers wait.

Time Response time Target: the SLO says healthy below this line Average of all requests Checkout endpoint, and the users who call it
Healthy average, unhappy users: the overall response time is inside the target while the checkout endpoint is far outside it.

Fred Hebert warns that metrics are rough stand-ins for the things people actually care about. Aggregating measurements can hide details needed to understand a problem.

A healthy error budget is not proof that a large failure is unlikely. Lorin Hochstein argues that counting smaller incidents does not reliably reveal the risk of a major one. Near misses and other warning signs may never affect the budget at all.

An SLO that nobody uses is another reporting number. It takes attention and gives the appearance of control.

What a first SLO looks like

A first SLO usually covers one journey that matters to users, such as completing checkout. It defines a good attempt from the user's point of view, including whether it completes in a useful amount of time. The measurement has to see that outcome, including failures that happen outside the server.

The target applies over a stated period. It comes from what the team knows about user needs and current performance. It is a starting point and changes as the team learns more.

The SLO also names who reviews the result and what happens when the target is missed, such as investigating a pattern, changing an alert or making room for a reliability fix. An SLO that never informs a decision is a candidate for change or removal.

Sources