Service Level Objective

Start measuring quality and the next problem arrives quickly: the number is there, and nothing says whether that number is acceptable. Response time for opening a document moves from 0.4 seconds to 1.1, and every week the same meeting decides from scratch whether to act now or look at it later.

Pagedeck had that conversation on repeat. Theo would point out that no user had complained yet, so it could wait. Mia would point out that waiting was exactly what happened before last month's incident. Both had grounds and neither had a standard, so the outcome came down to whoever was more worried. Alerting was in the same state: nobody could remember why the threshold had been set at a one percent failure rate.

One more thing sat on top of that. With no stated target, the effective target becomes 100 percent. Every failure counts as an incident, so the team ships less and postpones more. A service level objective (SLO) is the one line written to settle both problems at once. It fixes in advance what counts as normal, and it treats whatever sits under that line as failure the team is allowed to spend.

It is more a decision than a calculation, but there is an order to it. Four steps.

1. Pick the value the target applies to. It has to measure something users do, like the success rate of saving a document. How that value gets measured, and what counts as good, should already be settled on the service level indicator (SLI) side.
2. Choose the level. Look at historical data before writing anything down. Put 99.99 percent on a service that measured 99.84 percent over the last three months and it starts out in violation in week one. The number usually lands at or one notch above the current level.
3. Attach a period. A rolling 28 days, recalculated daily, is the common choice. A target with no period cannot be judged.
4. Convert the remaining slack into minutes or request counts. Twenty-eight days is 40,320 minutes, so a 99.9 percent target allows about 40 minutes of failure. At 99.95 percent it is 20 minutes; at 99.99 percent, 4 minutes. Counted in requests, 0.1 percent of 12.4 million requests is 12,400 of them.

What comes out of step 4 is the error budget: the share of failure you may spend while still meeting the target. That is what makes an SLO behave differently from other goals. With 40 minutes left there is room to attempt a risky deploy; with 38 minutes already spent, this week goes to stabilization instead.

The finishing touch is hanging alerting off that line. Alerting is the mechanism that contacts whoever is on duty when a condition is crossed, and it works better against the rate at which the budget is being consumed than against the raw value. Nobody can explain why the threshold is one percent, but "half of a 28-day budget went in six hours" explains itself.

A good SLO is one that actually holds and that changes behavior when it doesn't. A target that gets violated with no consequence is decoration, not a target.

Three things to weigh when picking the level.

1. Price out each additional nine. Going from 99.9 to 99.99 percent shrinks the allowance from 40 minutes to 4, and holding that means redundant servers, multiple regions, and automated recovery. The cost climbs by roughly ten times while the difference users feel is close to nothing.
2. Ask whether users can perceive the difference at all. If the office wifi your customers sit behind already drops more often than that, an extra nine on your side changes nothing they experience.
3. Check that it will not sit in permanent violation. A target that is always red teaches the team to ignore the color within two weeks, and from then on it prevents nothing.

Not writing 100 percent belongs on the list too. It means allowing zero failure, which rules out deploys and experiments alike.

Different services carrying different numbers is normal. Payment and login at 99.95 percent with document search at 99.5 percent is more useful for real decisions than one number covering everything. Search being slow for 20 minutes and payment being blocked for 20 minutes are not the same event to a customer.

"Let's set the save success SLO at 99.9 percent over 28 days. That's 40 minutes of budget."

Stating the target and the allowance together so the standard is fixed.

"We've already spent 70 percent of this month's budget. Let's move the risky deploy to next month."

There is little slack left, so the rate of change should come down.

"That target has been in violation for three months. Either lower it or staff the work."

A line nobody can hold is not functioning as a standard.

Pagedeck runs 99.9 percent on save success and 99.5 percent on document open response, both over 28 days. Theo put the remaining budget at the top of the dashboard in minutes. Seeing minutes rather than a percentage makes it obvious what the week can afford.

Mia changes the plan in weeks where the budget drops below half. People move off new features and onto whatever caused the drop, and in a month where the budget comes through nearly untouched, she pulls a postponed experiment forward.

The most common mistake is assuming higher is better. The word target carries that implication, so the reading is natural. But this number is a commitment rather than an ambition, and a commitment you cannot keep does not function as a standard. Write 99.99 percent against a service measuring 99.8 and the target starts red in month one and stays red. Leave it there and the team comes to treat red as the background color, so nobody reacts in the week things genuinely get worse.

The second is reading a violation as somebody's fault. Missing a target sounds like a mistake. But this structure begins by setting aside a share of failure on purpose. Spending the budget is normal, and a budget that comes through a full 28 days almost untouched reads as a signal that the team was more cautious than it needed to be. Once violations become a question of blame, teams start loosening the target on paper or finding reasons not to call an incident an incident.