Service Level Objectives: Start with the User Journey

A useful service level objective starts with an outcome a user needs, defines which attempts count, and sets a target over a stated time window. Choose the measurement after defining that outcome. CPU utilization can help explain a slow service; it does not, by itself, tell you whether a person completed the task.

Consider a team building a document-preview service. A user submits a supported document and expects a usable preview. The queue can accept the request, every worker can be running, and the journey can still fail because the preview never appears. An objective that measures only successful enqueue operations would miss that failure.

This guide develops a synthetic objective for that journey. The event counts and target below are illustrative. A local arithmetic fixture checked the calculations; no production service or monitoring system was evaluated.

Name the outcome before choosing the counter

The Google SRE Workbook distinguishes the service outcome you want to assess from its measurement implementation. That distinction makes it possible to discuss blind spots before adopting a convenient dashboard.

For our preview service, a proposed outcome is: a valid submission produces a retrievable preview within 60 seconds. “Retrievable” matters. A worker writing a completion event is insufficient if the resulting object cannot be opened.

The team would need to settle what a submission means. Does retrying the same upload produce another attempt or refer to the original operation? Does the deadline start when the browser sends bytes, when the gateway receives the request, or after upload validation? Those choices change the measured experience.

Write a short measurement contract:

This deliberately begins after admission. It therefore needs a separate view of admission failures: rejecting valid submissions because capacity is exhausted must remain visible. A team could instead choose a broader denominator beginning at the gateway attempt, but it would need reliable evidence for eligibility even when admission fails. State the boundary rather than silently changing it when failures rise.

Treat missing observations as a measurement problem

Suppose a submission has a start record but no terminal record. Once its deadline passes, our contract counts it as bad, even if a preview arrives later. Before the deadline, it is pending. The query must allow that evaluation delay rather than declaring recent, unfinished work a success.

An absent start record is different. The backend cannot count a request it never observed. Client-side or edge measurements can reveal some of that missing population, but those collectors have failures too. Google's SLI discussion explains why server-only measurement may miss user-visible problems.

Use an instrumentation-coverage indicator alongside the SLI. For example, compare accepted operation identifiers with the records used to evaluate their deadlines. Investigate gaps instead of interpreting an empty query as perfect reliability. A no-traffic interval should be reported as no observations, not as evidence that the service achieved its target.

Do not add customer identifiers as unrestricted metric labels to reconstruct every journey. Keep aggregate dimensions bounded and use an authorized diagnostic record for individual investigations. Our guide to logs, metrics, and traces develops that separation.

Make the error budget concrete

For illustration, choose a target of 99.5% good outcomes. This is a hypothetical planning value, not a recommendation for preview services. The appropriate target needs evidence about user tolerance, current behavior and the cost of improvement.

Suppose the evaluated window contains 20,000 eligible submissions, of which 80 are bad:

good ratio = (20,000 - 80) / 20,000 = 99.6%
allowed bad outcomes = 20,000 × (1 - 0.995) = 100
remaining allowance = 100 - 80 = 20

The event-based budget follows the definition documented in Google Cloud's service monitoring concepts. It is an allowance for this population and window. It is not 20 minutes of downtime, and it is not permission to deliberately fail 20 customers.

In a rolling window, old events leave as new events arrive. The absolute allowance can change with traffic. Record the numerator, denominator, target and interval together so someone can reproduce the reported percentage.

Our Python fixture checked seven cases, including the example, exact exhaustion, overspend, no failures, no events, low traffic and invalid counts. It returned 99.6%, an allowance of 100 and 20 remaining for the main case. That establishes arithmetic correctness for these inputs; it does not validate event collection or prove that 99.5% is an acceptable target.

Decide what a breach changes

An SLO has little operational value if missing it changes nothing. Agree on a response before the budget is exhausted: who investigates, what release risks receive additional review, and how recovery is assessed. A blanket freeze may itself obstruct a reliability fix, so the policy needs an explicit route for corrective work.

Keep alerting distinct from the monthly or rolling summary. A service can be within its window-wide objective while a new failure consumes the remaining allowance rapidly. Google's alerting chapter discusses burn rates and the difficulties of sparse traffic. Our 20 remaining events are a planning observation, not a ready-made paging threshold.

Review the objective with a concrete incident. Did a reported breach correspond to users being unable to obtain previews? Did users complain while the SLI remained healthy? Did the measurement exclude the failure? Use those questions to revise the contract, preserving the history of definition changes so that a better-looking chart is not mistaken for a better service.

Evidence note: primary documentation reviewed October 28, 2026. Seven synthetic arithmetic checks passed with Python 3.14.2. No live telemetry, user study, monitoring backend or production reliability result is reported.