Choosing an SLO: what the extra nine asks you to change

A customer is waiting for a report before leaving for a meeting. Dispatch's team is looking at two possible targets on a planning sheet: 99% and 99.9% of reports ready on time. The extra nine takes almost no effort to type. In the imaginary service below, it asks the team to allow 9,000 fewer missed reports.

The measure comes from the previous lesson: the correct report must be downloadable within five minutes after Dispatch accepts the request. For this hypothetical plan, assume one million eligible requests over 28 days and reliable measurement. An SLO, or service-level objective, sets the target for that measure over that window. Choosing it means deciding what the team will work to deliver, not merely where to draw a line on a chart.

The extra nine is 9,000 reports

At 99%, one request in a hundred may miss the measure: 10,000 out of a million. At 99.9%, that allowance falls to 1,000. These are reports, not minutes of downtime. A failure during a busy hour can affect many more requests than one during a quiet hour.

None of those customers volunteered to supply the missed part of the percentage. The allowance helps a team decide when reliability needs more attention. It does not make the missing report less important to the person waiting for it.

What happens when the report is late?

A report someone can regenerate tomorrow creates a different problem from the only export accepted before an external deadline. Product and support colleagues can explain those consequences. Engineering can show how the service behaves today and what might improve it. The choice needs both views: the experience you want to provide and the work required to provide it.

Suppose this hypothetical service delivered 99.6% on time last month. Late reports clustered during storage maintenance, and customers tolerate a documented retry for nonurgent work. A 99.9% target now raises a specific question: what will change about those maintenance delays? Changing the target alone will not make the reports arrive sooner. Choosing 99% without considering deadline-driven customers may be an equally poor answer to a different part of the problem.

The service owner needs to connect the target to a decision the team can carry out. For example, repeated rapid consumption of the allowance could pause risky feature releases while the team repairs the maintenance behavior. Now the target has a consequence someone can approve, rather than a percentage everyone hopes to reach.

A smaller allowance does not come with a price tag

Moving from 10,000 permitted misses to 1,000 shrinks the allowance tenfold. It does not establish that the repair will cost ten times as much. One configuration correction might remove a concentrated cause. A limitation in a shared dependency might require a much larger redesign. The cause tells you more about the bill than the number of nines does.

For the storage-maintenance delays, there are several different possibilities to examine. Could the work move to a quieter time? Could buffering absorb the interruption? Would more capacity help, or is processing capacity not what holds the exports up? Extending the promised turnaround is another option, but that changes what the customer receives. Similar percentages can come from quite different service promises.

The discussion can then become practical. Product identifies which delays hurt. Engineering explains which change addresses them. The owner decides what work to fund. The target records that agreement, and later results show how well the chosen work served it.

The customer's agreement is a separate promise

An internal operating target is not the same as the customer's contract. An SLO guides operation; a service-level agreement, or SLA, is an external commitment with its own scope and consequences. Writing a new number on this planning sheet does not amend it. The actual agreement needs to be checked when deciding which promises constrain the choice.

The customers being counted matter just as much. Removing difficult tenants from the denominator, the total at the bottom of the fraction, makes the percentage look better without delivering their reports sooner. Genuine service tiers can have separate measures and commitments. Their populations must be explicit, rather than disappear when they become inconvenient to the target.

Put the work beside the percentage

A useful proposal can fit in a paragraph: the measure, 28-day window, target, customer reason, expected work and cost, approving owner and review point. One team might propose a temporary 99% internal target while funding the maintenance repair, then revisit it after representative results. Another might choose 99.9% with the required work already funded. The explanation should make clear why the particular choice can be supported.

If the measurement misses failed requests, the calculation needs attention before it can support either target. If conversations with customers overturn the assumed tolerance for retries, the proposed promise needs another look. Last month's average cannot settle what the records omitted or what a customer needed.

The person waiting to leave for the meeting will not benefit from an extra nine on its own. They benefit from fewer reports arriving late. You can now explain what the tighter target asks the team to prevent, which work could prevent it and who will support that work. Those are the decisions that give the percentage a useful job.

Sources

Implementing SLOs discusses target selection, iteration and ownership. Every Dispatch volume, target and planning alternative in this exercise is hypothetical.