How to choose an SLO for work users need completed

Imagine uploading a report you need for a meeting. The app says it accepted the upload. Five minutes later, you go to open the report and it still isn’t there. The upload endpoint can record a success while you are still waiting to use the file.

If the service promises to make accepted files available within five minutes, measure whether people can retrieve those files by then. The upload response tells you where the work started. Retrieval tells you whether it finished.

A service level indicator (SLI) measures the result: the share of eligible uploads users could retrieve within five minutes. A service level objective (SLO) sets a target and a window for that measure. One example is 99.9% over a rolling 28 days. A service level agreement (SLA) is a separate agreement with users that spells out consequences if an agreed level is missed.

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.

Count uploads whose deadlines have passed

Say 100 accepted uploads have reached their five-minute deadline. You can show that 90 were retrievable in time and 10 missed the deadline. The SLI is 90 out of 100, or 90%. Keep those 10 in the denominator even if the files arrive later. A newer upload that still has time left is pending; include it when its deadline passes.

That example assumes you can verify what happened to all 100. If completion data is missing, show how many outcomes are unknown and how that limits the SLI. A file you know missed its deadline and a file you cannot verify point to different problems. The measurement completeness lab shows how missing observations can change the result you think you have.

Accepted uploads are also a deliberate boundary. They leave out attempts that fail before the server accepts them, including failures your server never sees. If that is a meaningful source of user harm, measure those attempts separately with client evidence or a synthetic check that exercises the whole upload. The SRE Workbook’s guide to data processing pipelines explains why the final result can be missing even when each stage reports success.

Set the target with evidence

Start with the time users can actually wait. Then check recent performance, which dependencies could keep you from meeting that deadline, and what it would cost to improve. If one group relies on a shorter deadline for a different kind of work, measure that group on its own terms. A single percentage can look fine while a smaller group keeps waiting.

A target also gives the team a way to talk about the scale of a miss. With one million eligible requests in the window, a 99.9% request-based SLO allows 1,000 bad requests. It does not tell you how many minutes the service was down. The Workbook’s guide to implementing SLOs walks through defining good events and choosing an initial target.

Decide what the result changes

Agree who owns the SLO and what happens when bad outcomes use up the budget. If the upload endpoint keeps accepting work while retrieval falls behind, look at the queue, workers, and storage path before trying to make the endpoint even more available. Then use the error budget policy to decide whether releases should continue or the team should make time for that repair.

If you change the deadline or who counts, record the date and the old definition. The team should be able to tell whether uploads got more reliable or the measurement changed. Before settling on an SLO, ask what you would fix if it missed. If the answer still leaves the report out of reach, follow the upload a little further.