What makes a service reliable?

A report-export service can return a successful response while leaving the person who requested the report with nothing to download. The web process is alive, the request was accepted and the useful work is still unfinished. If the service dashboard measures only the first two events, it can describe a healthy system while users wait.

Site reliability engineering starts by making that difference explicit. SRE applies engineering to operating services: define the behavior people depend on, find out how consistently the service delivers it and choose work that improves that result. An on-call rotation helps respond when things go wrong, but reliability also depends on what the service measures, how it changes and whether anyone can recover it.

In this lesson, you will write the first page of a reliability plan. You need no monitoring product or production access. The task is to describe one useful service outcome well enough that someone else can tell when it happened.

Follow the report to the person who needs it

Dispatch is a fictional service used throughout this learning path. A user requests a report, the API accepts an export job, a worker creates a file and the user downloads it. All service details and numbers in this lesson are constructed teaching material.

The service has three distinct milestones:

Milestone	What happened	What it does not establish
The API accepted the export.	Dispatch recorded a job and returned its identifier.	The worker has produced a file.
The worker completed the export.	Dispatch reports that the output is ready.	The intended user can retrieve the correct file.
The user downloaded a valid report.	The requested result reached its consumer.	Other users or later requests will have the same result.

Each milestone can matter, but they answer different questions. A successful submission helps show that a user can start the operation. It cannot establish that the operation finished. Likewise, a completed job record is useful evidence, but a broken download link can still prevent the user from obtaining the result.

A useful first description of this service is therefore, “A user can request a report and retrieve the correct result within the time they need it.” That gives the reliability work a direction. We still need to decide which reports and users are covered, how much time they need and what evidence is available. Those decisions belong in the service definition rather than being hidden inside a dashboard query.

Decide what a successful operation means

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

An eligible export in this example is one accepted from an authenticated user for a supported report type. Requests rejected before acceptance are outside this particular completion measure. They still matter to the full user journey and need a separate submission measure; excluding them from one denominator does not make them harmless.

A good outcome requires the correct report, access for the intended user and completion within the deadline. A file that arrives promptly but contains another user’s data fails that definition. A correct report that appears an hour after it was needed also fails the timing condition. Reliability includes the behavior the consumer needs, rather than simply a process remaining available.

The deadline raises an implementation question: where do we record the start and finish? The API can record acceptance time, while the worker can record when it marks a file ready. Those records support an acceptance-to-ready measurement. They do not directly prove that an authorized user can download the file. A download-path check or suitable user-side evidence would cover that additional condition.

Write down that gap. A narrower available measurement can be useful while the service gains better coverage, provided its label does not claim to measure the whole experience.

A percentage is only as useful as its definition

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

Recorded outcome	Export count
Confirmed correct and downloadable within five minutes	960
Confirmed correct and downloadable, but late	20
Confirmed failed	10
Completion outcome not observed	10
Total eligible exports	1,000

We can confirm that 960 of 1,000 exports met the stated condition, or 96%. We cannot yet claim that exactly 96% was the true good-outcome rate, because ten outcomes are unknown. If all ten were good, the rate would be 97%; if none were good, it would remain 96%. That range follows from the supplied counts and assumes no other collection errors.

The 20 late exports and 10 failures establish bad outcomes. The missing ten establish a measurement gap. Your eventual operating policy needs to say how missing observations affect decisions, but the report should retain the distinction instead of silently treating them as success.

This ratio is the beginning of a service-level indicator, or SLI: a defined measurement of service behavior. A service-level objective, or SLO, would set a target for that indicator over an agreed window. We have not chosen an SLO here. A target requires a discussion of user needs, service capability, costs and the decisions it will influence. Copying a familiar percentage would skip that work.

Turn the definition into a small reliability plan

Use the Dispatch example to fill in the following brief before reading the worked answer below:

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

A defensible answer names users requesting supported reports and follows accepted exports through a correct, authorized download within five minutes. It keeps rejected submissions outside this completion denominator while acknowledging their effect on users. It records that the sample has ten unknown outcomes and does not invent why they are missing.

For the next check, assign a role rather than pretending a real team accepted work. In the tabletop, the service owner could ask the instrumentation engineer to reconcile accepted job identifiers against completion and download evidence. The purpose is to learn whether the missing records represent unfinished exports or missing observation. Adding workers before answering that question might improve a real capacity problem, but the current packet does not establish one.

Your brief is complete when a second reader can describe what counts as success, identify an outcome the health check could miss and explain what the existing evidence cannot establish. If you choose a different service, change the consumer, operation and deadline together. A database write, a batch pipeline and an interactive request should not inherit Dispatch’s completion rule without review.

Keep this brief. The next lesson follows Dispatch’s API, queue, worker and storage dependency so the measurement and recovery plan can be attached to the places where the work happens.

Sources and example scope

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