SLO and Error Budget Service  ·  View 06 of 21  ·  People and journeys

Journey — Declaring an SLO

A service team and a product owner try to write a target that means what a user would mean.

Editable source SVG draw.io All views
Service team lead with the product owner Goal — An SLO that means what a user would mean Trigger — Checkout is now a critical journey; it needs a target Done when — A merged definition that the team will not quietly widen later 1 · Agree the journey with product 2 · Write the predicate ◆ moment of truth 3 · Name the denominator ◆ moment of truth 4 · Review pull request 5 · Live reconciled What they do Picks "complete a checkout" Drafts good = 2xx under 800 ms Argues about 499s Excludes bot traffic Opens a PR Watches first buckets What the platform does Offers the journey catalogue Checks the outcome cube covers it Rejects implicit denominator Rejects 99.999% monthly Dry-runs over 28 days of history Versions it, effective-from How it feels Clear Workable Stuck Where it hurts Is 800 ms the user's number? Nobody owns the 499 answer What answers it Journey catalogue, not endpoints Cube dimensions are declared Implicit denominators rejected Dry-run on real history Versioned, so it can be corrected Journey — Declaring an SLO for a Journey The trough is the valid-event denominator. It is where an SLO is really defined, where it is later gamed, and the one thing the platform refuses to let a team leave implicit. v 1.0 · owner Reliability Architecture · date 2026-10

The trough, and what answers it

  • The low point is the valid-event denominator. It is where an SLO is really defined, where it is later quietly widened, and the place two reasonable engineers disagree about client-cancelled requests for forty minutes.
  • The platform's answer is refusal: a definition that leaves the denominator implicit is rejected, and so is an objective whose budget is finer than minute buckets can resolve (ADR-15).
  • Dry-run over 28 days of retained history makes the argument empirical rather than theoretical before the definition merges.

What the architecture owes this journey

  • The outcome cube's declared dimensions, which bound what a predicate can say and therefore what can be redefined retroactively (ADR-03).
  • Versioned immutable definitions with an effective-from timestamp, so correcting a mistake produces a corrected history rather than a silent rewrite (ADR-05).
  • A journey catalogue, so the unit of reliability is something a product owner recognises rather than an endpoint path.

Risks

  • Ownership of the definition is left with the service team in this design. That makes targets achievable and comparability across 400 services weak — the open question the package does not close.
  • The cube's dimensions are fixed at emission. A predicate the team wants later and the cube cannot express requires a change in a system this platform does not own.
◀  Journey — The 02:00 Burn-Rate Page All views Layered Architecture  ▶
Solution Architecture v1.0 · Microsoft Azure · Reliability Architecture · 2026-10 · 21 views · 17 architecture decision records06-journey-declare-an-slo