Choosing an SLO for the work users need completed

You upload a file, see a success message and close the window. Later, the file is missing. Which part of the service succeeded? A service-level objective, or SLO, is useful only when its target describes the outcome people were relying on. For this example, that means following the upload far enough to establish that it can be retrieved.

The success message could mean several things: the receiving endpoint got the file, the queue accepted it, or the service saved it where the customer can retrieve it. Choose one and the reliability percentage follows. Choose the wrong one and the dashboard can stay green while the person who closed the upload window searches for a file that is not there.

The vocabulary is easier to keep straight once that outcome is clear. A service-level indicator, or SLI, is the measurement, such as the fraction of accepted uploads available within the deadline. An SLO sets its target and time window. A service-level agreement, or SLA, is a separate agreement that can attach consequences to performance. They can concern related behavior without being interchangeable promises.

For queued uploads, success occurs after acceptance

Consider a hypothetical upload service that queues files before saving them durably. Its endpoint continues returning success while the downstream processing fails. Counting accepted requests describes the front door, but cannot establish whether the files will be available afterward.

If durable completion is the intended outcome, the SLI needs evidence at that state. If speed is part of the promise, it also needs completion timing. A synchronous service might measure the fraction of requests finishing within a threshold; asynchronous work may require a completion-time or freshness measure that continues beyond the initial response.

To make that outcome measurable, a hypothetical completion SLI could measure the share of accepted uploads that become retrievable within five minutes. For 100 uploads whose deadline has passed, ninety on-time completions and ten missing files give 90 ÷ 100 = 90%. Dividing by only the ninety completed files would report 100%, silently dropping the failures. Count eligible accepted uploads, including those without a completion record, and distinguish newer pending uploads from overdue work. Five minutes is illustrative, not a recommended target. Google’s pipeline guidance describes completion-time SLOs; its event-delivery example checks completeness by comparing published and delivered events.

The absence of a completion record needs one more distinction. If a complete observation system establishes that an eligible upload missed its deadline, that is a bad event under this definition. If the completion collector itself lost evidence, the outcome is unknown until another source resolves it. Report that measurement gap separately rather than removing the upload or silently calling it successful. The measurement-completeness lab compares known failures with missing observations using synthetic event records.

Observation points have different blind spots. Server-side counts cannot see requests that never reached the server, where client observations or synthetic transactions may help. A downstream completion record answers another question: did accepted work finish? Explain what the selected source establishes and which population it includes before deciding what its percentage means.

An indicator at durable completion also changes the recovery question. The team needs the queued files to be saved successfully, even if the receiving endpoint has been healthy throughout. Restoring that endpoint alone cannot resolve the incident. The target and response policy should protect the completed upload, which is the task the customer needs.

One objective may not adequately represent every customer journey. Use a small set when necessary and inspect consequential populations that overall success could conceal. Simplifying the dashboard is not a sufficient reason to hide a different user outcome inside a single average.

An exact target cannot repair a vague definition. Tightening 99% to 99.9% asks for more consistency in whatever you chose to count. If that event is only queue acceptance, the extra nine still says nothing about the missing file. First decide what good service means, then decide how consistently the team should deliver it.

What a 99.9% target allows

Once the outcome is clear, choose a target using customer needs, historical performance, dependency constraints and engineering cost. A tighter percentage can demand substantial work while leaving the user's main difficulty elsewhere in the journey. The target should express the experience the team has decided is worth improving, rather than reward a more impressive number.

Suppose the target is 99.9% request success in a window with one million eligible requests. The permitted bad-event fraction is 0.1%, yielding an allowance of 1,000 bad events. This is a request-based error budget. It does not automatically become a fixed number of downtime minutes, because a minute at high traffic and a minute at low traffic contain different amounts of work.

Google’s SLO implementation chapter offers examples for choosing indicators and objectives. Applying them locally still requires deciding what completion means and which target fits the customers. Those choices give the arithmetic its operational significance.

When failed uploads consume the budget

If queued files are failing and consuming the budget, the objective should inform repair priority, release risk and incident response. An error-budget policy records the agreed consequences before a release becomes disputed. It gives product and engineering a shared basis for choosing what changes next.

The policy depends on trustworthy measurement. Validate the pipeline and revisit the definition when the product or user population changes. Retain earlier definitions so a trend can be interpreted as a change in observed service behavior or a change in what was counted. Those are different reasons for the same graph to move.

An SLO connects a user experience to a decision

Read diagram description

Define the measurement boundary and eligible population first. An SLI measures behavior; an SLO sets its target and window; the resulting error budget informs an agreed policy. An SLA is a separate agreement. Diagram labels: User operation: What experience must the service protect?; SLI: Good eligible events ÷ all eligible events; SLO: Target for that indicator over a defined window; Error budget + policy: Calculate the allowance and agree what changes.

Now follow the upload one last time. The objective names when it must become retrievable, the measurement can distinguish timely completion from missing work, and the policy says what the team will do when that experience deteriorates. The percentage has a job because the customer’s missing file has a place in the definition. A healthy receiving endpoint can no longer answer the wrong question on everyone’s behalf.