Reliability begins with the report the customer can use

“Your report is on its way.” In the fictional Dispatch service, that reply can arrive even when the report never reaches the person who requested it. The website stays up. The customer still has nothing they can use.

Site reliability engineering applies engineering to the complete promise: what people depend on, how consistently they receive it and what would improve the result. On-call response is one part. Capacity, safer changes and a way to recover when something breaks belong alongside it.

Before choosing a target, follow a report far enough to recognize success from the customer’s side. Dispatch’s fictional records let us do that without production access or a monitoring product.

Find the point where the customer has what they need

Dispatch is the fictional service used throughout this learning path. A user requests a report, an API accepts the export job, a worker creates a file and the user downloads it. Every service detail and number here is constructed teaching material.

Three moments in that journey can sound like success while establishing different things:

The first reply proves acceptance. A completed job proves the worker finished its part. Neither proves the download link works for the intended account. Following the file into the customer’s hands makes the missing condition visible.

A useful first description is “A user can request a report and retrieve the correct result within the time they need it.” Now the team has a direction, but also decisions to make: which users and reports count, how much time they need and what can be observed. Put those decisions in the service definition, not out of sight inside a dashboard query.

For another service, the result might be a completed payment or a saved document that opens again. A server reply can matter without completing that journey. Dispatch is one small example of following the work far enough.

Build the ability to keep that promise

Once the outcome is clear, engineering determines how consistently the service can deliver it. Dispatch might need processing capacity that keeps up with accepted work, recovery when a worker fails and a release process that catches broken exports. Measurement can show the promise slipping. It cannot supply those capabilities on its own.

Those choices have costs. Spare capacity can absorb a surge and sit idle on a quiet afternoon. A second recovery route can remove a dependency while adding another system to maintain. Google’s introduction to SRE places these tradeoffs within SRE. The goal is the experience people need, not a failure-free machine at any price.

More workers might help an overwhelmed queue. They would not repair a download link that rejects the intended account. Before paying for capacity, find where the report stopped. The outcome and its evidence guide the engineering choice.

Define which exports count as good

For this exercise, the fictional product owner requires an eligible export to produce a valid, downloadable report within five minutes of acceptance. That is a training assumption, not a recommended deadline for every product. A monthly data extract and a checkout receipt can have very different timing needs.

Here, eligible means accepted from an authenticated user for a supported report type. Requests rejected before acceptance do not enter this completion measure. They still affect the user journey and need a separate submission measure. Leaving them out of one denominator does not make them harmless.

A good result needs the correct report, access for the intended user and completion before the deadline. Another user’s data arriving promptly is a failure. So is the correct report arriving an hour after it was needed. Reliability includes the behavior the consumer needs, not simply a process staying available.

Where can we record the start and finish? The API can record acceptance; the worker can record when it marks the file ready. That supports acceptance-to-ready timing, but not direct proof of authorized download. A download-path check or suitable user-side evidence covers that additional condition.

Write down the gap. A narrower measurement can still be useful while coverage improves, as long as its name does not claim to describe the whole experience.

Keep the ten unknown outcomes in the count

Consider these 1,000 synthetic eligible exports. Assume the acceptance count is complete and every export has had enough time to pass the five-minute deadline.

We know 960 were correct, downloadable and on time: 96%. The ten unobserved outcomes stay among the exports Dispatch accepted. If all ten were good, the underlying rate would be 97%; if none were good, 96%, assuming no other collection error. The blank outcomes tell us what remains unknown.

Twenty late exports and ten failures establish bad outcomes. The other ten establish a measurement gap. An operating policy must say how missing observations affect decisions, but the report should not erase the distinction or silently count them as successes.

Counting the agreed result across the agreed exports gives a service-level indicator, or SLI. A service-level objective, or SLO, would add a target and time window. We have not chosen one here. That choice needs user need, service capability, cost and a clear idea of which decisions the target will change.

Give the next check a particular job to follow

Use this brief to put the promise and the remaining gap in one place, then compare it with the worked explanation below:

Service and consumer:
Useful operation:
Eligible population:
Good outcome and deadline:
Evidence currently available:
Important measurement gap:
Team responsible for the next check:

Begin with the waiting person: an authenticated user requested a supported report and Dispatch accepted it. Success means that person can download the correct report within five minutes, not merely see “ready.” Rejected submissions stay outside this completion denominator but still matter. The ten unknown outcomes remain unknown; a brief cannot fill in events the record lacks.

Choose one of those ten accepted job IDs for the next check. In the tabletop, a service owner could ask an instrumentation engineer to find completion and download evidence; those are fictional roles, not an actual team accepting work. A ready timestamp would locate the worker’s part, but the intended user’s access to the correct file would still need support. Without the records, we cannot tell whether work stayed unfinished or the outcome went unobserved. The packet has not established a capacity problem that more workers would solve.

Another reader can now ask, “Where is the download evidence for this accepted job?” That is more useful than asking whether Dispatch was up. For a different service, reconsider the consumer, operation and deadline together. A database write, batch pipeline and interactive request should not inherit this completion rule without review.

Keep the brief beside the next lesson’s map. The queue, worker, storage and download path belong there because they help deliver the report. The initial reply is still useful. Now it sits inside a promise specific enough to ask where it can fail.

Sources and example scope

The engineering role of SRE is introduced in Google’s SRE introduction. Service Level Objectives and Implementing SLOs support SLIs, SLOs and user-relevant measurement. The site’s error-budget worksheet keeps eligible events, measured outcomes and decision policy distinct. Dispatch, its deadline and counts are constructed examples. The original calculations were checked separately; no production reliability or user acceptance was measured.