SLOs should follow user journeys

Every service can be green while the user journey is broken.

The API returns 200, the queue accepts the job, the payment provider authorizes, and the email service reports delivery. The customer still sees a spinner, receives no confirmation, retries, and creates a duplicate order. Component health did not add up to product reliability.

Google's Art of SLOs starts its worksheet from a user journey and the people who care about it. That ordering keeps a target connected to a real promise.

I would define the actor, entry event, success event, time boundary, valid exclusions, and evidence source before choosing the percentage.

Reliability becomes useful when an error budget can change a product decision.

Choose a meaningful journey

The SLO should protect an outcome users and the business recognize, especially one where unreliability changes trust or value.

I would pressure-test that decision with four questions:

• Who is the user?
• What are they trying to finish?
• Why does failure matter?
• Which journey deserves a target first?

The failure mode here is starting with the easiest service metric to collect. In products where one user outcome crosses browser code, APIs, queues, third parties, asynchronous jobs, notifications, and recovery paths that can each look healthy while the overall task fails, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a ranked journey inventory. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is a reliability target tied to product consequence. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a ranked journey inventory beside the question “Who is the user?” before the first implementation review. The next pass would use “What are they trying to finish?” to test the boundary, then “Why does failure matter?” to expose the state most likely to be missed. I would keep “Which journey deserves a target first?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports a reliability target tied to product consequence.

Define entry and success

A journey needs observable boundaries that distinguish intent, valid attempt, durable completion, and merely accepted work.

The practical review starts here:

• What proves intent?
• What state counts as complete?
• Must the result be visible?
• How are retries grouped?

Those questions keep calling an API acceptance event successful completion from becoming the default. I would capture the decision in an entry-to-success event contract, then use it while the work is still cheap to change. For user-centered reliability management, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like a numerator that represents the promised outcome. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make an entry-to-success event contract part of the working surface. I would use it to answer “What proves intent?” while scope is still flexible, and “What state counts as complete?” before code or content becomes expensive to unwind. During QA, “Must the result be visible?” and “How are retries grouped?” become concrete checks rather than discussion prompts. That sequence turns user-centered reliability management into something the team can operate and gives me a specific outcome to report: a numerator that represents the promised outcome.

Design the denominator

Eligibility, cancellations, validation errors, retries, bots, and unsupported states can radically change the reported reliability.

Before implementation, I would answer:

• Which attempts are valid?
• Which exclusions are product choices?
• Are repeat attempts one journey?
• What remains unknown?

The artifact is a denominator decision log. Its job is to expose the tradeoff early enough that design, engineering, support, or product can disagree with something concrete. The common trap is removing inconvenient failures until the SLO looks healthy; it moves uncertainty downstream and makes the final interface carry a problem the system never resolved.

For me, the useful receipt is a stable and defensible measure. That connects a journey SLO that measures whether a named user can complete a meaningful task within an acceptable boundary to an observable result instead of a process claim.

I would test this with one typical case and one boundary case. The typical case should make “Which attempts are valid?” easy to answer. The boundary should force a decision about “Which exclusions are product choices?” and “Are repeat attempts one journey?.” I would record both in a denominator decision log, including the part that stayed unresolved after the first pass. The final check, “What remains unknown?,” is where the artifact earns its place: it either supports a stable and defensible measure, or it shows exactly why another iteration is needed.

Set a user-relevant time boundary

Completion latency should reflect when the outcome stops being useful or starts changing user behavior, not a convenient percentile.

I would use these prompts during the working review:

• How long will the user wait?
• When do retries begin?
• Can work continue asynchronously?
• Which cohort needs a different bound?

If the team slips into copying the service's p95 into the journey target, the product can still look complete while its operating rule stays ambiguous. I would make a latency expectation backed by behavior the shared reference and keep it small enough to update as evidence changes.

The standard is a time objective connected to user experience. That tells me whether the decision helped the product, not merely whether the document was completed.

The working sequence is small: draft a latency expectation backed by behavior, review it against “How long will the user wait?,” implement the narrowest useful path, and then return with evidence for “When do retries begin?.” I would use “Can work continue asynchronously?” to inspect product consequence and “Which cohort needs a different bound?” to decide whether the result is stable enough to ship. This keeps copying the service's p95 into the journey target visible as a known risk and makes a time objective connected to user experience the release receipt rather than a hopeful conclusion.

Correlate without over-collecting

Cross-boundary measurement needs stable journey linkage while minimizing identifiers and avoiding raw user content.

I would pressure-test that decision with four questions:

• Which event carries correlation?
• Can IDs be scoped or hashed?
• Where does linkage break?
• How is deletion handled?

The failure mode here is adding a persistent user identifier to every log. In products where one user outcome crosses browser code, APIs, queues, third parties, asynchronous jobs, notifications, and recovery paths that can each look healthy while the overall task fails, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a privacy-aware journey telemetry schema. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is traceable outcomes with bounded data collection. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a privacy-aware journey telemetry schema beside the question “Which event carries correlation?” before the first implementation review. The next pass would use “Can IDs be scoped or hashed?” to test the boundary, then “Where does linkage break?” to expose the state most likely to be missed. I would keep “How is deletion handled?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports traceable outcomes with bounded data collection.

Segment failures by recovery path

The headline SLO should lead into client, API, queue, dependency, timeout, stale-state, and user-recovery segments.

The practical review starts here:

• Where did progress stop?
• Could the user recover?
• Was a duplicate created?
• Which owner can act?

Those questions keep building one percentage with no diagnostic route from becoming the default. I would capture the decision in a journey failure taxonomy, then use it while the work is still cheap to change. For user-centered reliability management, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like alerts that reach the team able to restore the journey. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a journey failure taxonomy part of the working surface. I would use it to answer “Where did progress stop?” while scope is still flexible, and “Could the user recover?” before code or content becomes expensive to unwind. During QA, “Was a duplicate created?” and “Which owner can act?” become concrete checks rather than discussion prompts. That sequence turns user-centered reliability management into something the team can operate and gives me a specific outcome to report: alerts that reach the team able to restore the journey.

Make third parties visible

Provider success, timeout, callback delay, and reconciliation can change the journey even when the internal system behaves correctly.

Before implementation, I would answer:

• Which dependency gates success?
• What evidence do we receive?
• Can the journey degrade safely?
• Who owns reconciliation?

The artifact is a dependency boundary inside the SLO. Its job is to expose the tradeoff early enough that design, engineering, support, or product can disagree with something concrete. The common trap is excluding provider failures from a promise the user still experiences; it moves uncertainty downstream and makes the final interface carry a problem the system never resolved.

For me, the useful receipt is honest reliability across external boundaries. That connects a journey SLO that measures whether a named user can complete a meaningful task within an acceptable boundary to an observable result instead of a process claim.

I would test this with one typical case and one boundary case. The typical case should make “Which dependency gates success?” easy to answer. The boundary should force a decision about “What evidence do we receive?” and “Can the journey degrade safely?.” I would record both in a dependency boundary inside the SLO, including the part that stayed unresolved after the first pass. The final check, “Who owns reconciliation?,” is where the artifact earns its place: it either supports honest reliability across external boundaries, or it shows exactly why another iteration is needed.

Use the error budget to decide

A budget should influence rollout pace, reliability work, feature investment, and exception handling before it becomes an executive chart.

I would use these prompts during the working review:

• What pauses when burn rises?
• Who can spend the budget?
• Which launch gets an exception?
• What restores normal operation?

If the team slips into tracking burn without changing priorities, the product can still look complete while its operating rule stays ambiguous. I would make an error-budget action policy the shared reference and keep it small enough to update as evidence changes.

The standard is repeatable product and engineering decisions. That tells me whether the decision helped the product, not merely whether the document was completed.

The working sequence is small: draft an error-budget action policy, review it against “What pauses when burn rises?,” implement the narrowest useful path, and then return with evidence for “Who can spend the budget?.” I would use “Which launch gets an exception?” to inspect product consequence and “What restores normal operation?” to decide whether the result is stable enough to ship. This keeps tracking burn without changing priorities visible as a known risk and makes repeatable product and engineering decisions the release receipt rather than a hopeful conclusion.

Validate the measurement

Synthetic journeys, support cases, client receipts, production sampling, and incident review should challenge whether telemetry matches user reality.

I would pressure-test that decision with four questions:

• Can a probe complete the task?
• Do support reports appear?
• What completion is invisible?
• Which event can lie?

The failure mode here is assuming instrumentation is correct because the query runs. In products where one user outcome crosses browser code, APIs, queues, third parties, asynchronous jobs, notifications, and recovery paths that can each look healthy while the overall task fails, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a journey measurement calibration review. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is evidence that the metric represents the experience. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a journey measurement calibration review beside the question “Can a probe complete the task?” before the first implementation review. The next pass would use “Do support reports appear?” to test the boundary, then “What completion is invisible?” to expose the state most likely to be missed. I would keep “Which event can lie?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports evidence that the metric represents the experience.

Show reliability as product work

A strong case study shows the user promise, measurement design, discovered blind spot, budget decision, recovery change, and outcome.

The practical review starts here:

• Which journey mattered?
• What did service metrics miss?
• How did the budget change scope?
• What became more reliable?

Those questions keep presenting uptime without the task it protected from becoming the default. I would capture the decision in a redacted journey SLO and incident receipt, then use it while the work is still cheap to change. For user-centered reliability management, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like credible evidence of product-minded reliability engineering. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a redacted journey SLO and incident receipt part of the working surface. I would use it to answer “Which journey mattered?” while scope is still flexible, and “What did service metrics miss?” before code or content becomes expensive to unwind. During QA, “How did the budget change scope?” and “What became more reliable?” become concrete checks rather than discussion prompts. That sequence turns user-centered reliability management into something the team can operate and gives me a specific outcome to report: credible evidence of product-minded reliability engineering.

What I would show in the work

The public version needs evidence from the work itself. For this topic, the first five artifacts I would reach for are:

• a ranked journey inventory
• an entry-to-success event contract
• a denominator decision log
• a latency expectation backed by behavior
• a privacy-aware journey telemetry schema

I would not publish all five at equal weight. One should orient the reader, one should reveal the hardest tradeoff, and one should prove the result. The others can live in a downloadable note or appear as supporting frames. That edit matters because a journey SLO that measures whether a named user can complete a meaningful task within an acceptable boundary becomes harder to understand when every process detail is treated as equally important.

I would also show one rejected direction. The useful version is specific: which option looked attractive, which constraint made it wrong, and what evidence supported the narrower choice. That gives an engineering manager something real to question and keeps the case study from reading like the final answer was obvious from the beginning.

# journey
merchant publishes product
Start at publish intent; succeed when durable product is visible through storefront read path.
# objective
99.5% within 60 seconds
Exclude user cancellation; keep validation failures separate; track unknown correlation as its own metric.
# decision
pause migration at 30% burn
Route alerts by failure segment, preserve manual recovery, and require recovery receipt before resume.

Resource path

The practical follow-up I would build is a journey SLO worksheet with user, task, entry and success events, valid exclusions, latency boundary, dependencies, measurement source, error budget, owner, alert, recovery, caveats, and review cadence. I am treating that as a resource backlog item, not pretending the adjacent downloads below are the same artifact. The related cards cover useful pieces of the workflow today; this specific file should only be published when its examples, fields, and instructions are complete.

The first version should stay concise: context, constraint, decision, evidence, owner, and follow-up. Its value would come from helping someone repeat this exact review, not from adding another generic PDF to the site.

Review checklist

The article-specific review questions are:

• Who is the user?
• What proves intent?
• Which attempts are valid?
• How long will the user wait?
• Which event carries correlation?
• Where did progress stop?
• Which dependency gates success?
• What pauses when burn rises?
• Can a probe complete the task?
• Which journey mattered?

I would add two editorial checks before publishing: can a recruiter find the point in the first minute, and can an engineer trace at least one claim to an implementation or production receipt? If either answer is no, the article needs another edit.

Implementation notes

For user-centered reliability management, I would write the implementation note before polish. It would name the changed surface, source of truth, owner, failure boundary, and verification path. Those details prevent the principle from floating above the actual code or operational workflow.

The proof signals I care about are specific to this article:

• alerts that reach the team able to restore the journey
• honest reliability across external boundaries
• repeatable product and engineering decisions
• evidence that the metric represents the experience
• credible evidence of product-minded reliability engineering

I would choose two or three of those signals for the first release rather than instrumenting everything. The strongest pair usually combines one direct behavior check with one operating check: a route and a data query, a keyboard path and a support state, a handler replay and a reconciliation result, or a migration count and a rendered screen.

The follow-up belongs in the note before shipping. It should say what remains temporary, what evidence would trigger another pass, and who owns that decision. That is how the first version stays intentionally narrow without making the boundary invisible.

Case-study packaging

I would structure the case-study version around the four visual lessons already established:

• A journey SLO connects a user promise to an operating decision.
• Journey evidence matures across system boundaries.
• The denominator is a product decision.
• A journey SLO should make the release rule explicit.

The opening frame explains the product pressure. The middle two show the decision moving through the system. The last frame is the receipt: what was checked, what held, and what remained unresolved. That order lets the reader move from product judgment into implementation detail without reconstructing the whole project first.

I would include one caveat tied to products where one user outcome crosses browser code, APIs, queues, third parties, asynchronous jobs, notifications, and recovery paths that can each look healthy while the overall task fails: a data limit, rollout boundary, unsupported state, external dependency, or result that is still directional. A precise caveat makes the evidence easier to trust because it shows where the claim stops.

The final test is whether the page creates a better conversation. If the artifact helps someone ask a sharper question about product judgment, implementation detail, or release proof in a live interview, it belongs in the story.

Interview angle

In an interview, I would explain this through a journey SLO that measures whether a named user can complete a meaningful task within an acceptable boundary. The story should start with the product pressure, then move into the system constraint, the artifact, and the proof. That order keeps the answer grounded. It also gives the interviewer several places to go deeper: data, frontend architecture, design systems, support, migration, accessibility, or release process.

The strongest version of the answer includes a tradeoff. I want to be able to say what I chose, what I left alone, and how I knew the work helped. That is more credible than presenting every project as a clean win.

The hiring signal

A journey SLO worksheet is a hiring signal because it shows I can connect technical telemetry to product consequence and use reliability targets to make prioritization decisions.

That is the level I want this site to communicate. The work should show taste, but it should also show operating judgment. It should make me look like someone who can enter a real product system, understand the messy middle, ship the useful version, and leave enough proof for the next person to trust it.