Journey-Level SLO

A single platform-wide availability target simultaneously over-engineers the paths nobody depends on and under-engineers the ones that carry the business. It also cannot be acted on: when it is missed, nothing in the number says which part to fix.

A per-service target has the opposite problem — it measures components rather than outcomes. A journey can fail while every service reports itself healthy, because the failure was in the composition, the timeout budget, or a dependency none of them owned.

Why it matters

The journey is the unit the business cares about and the unit an engineer can act on. It is also the only unit where the availability arithmetic is honest, because it includes every dependency in the path rather than only the ones you operate.

Implementation patterns

• Enumerate the journeys and rank them by consequence of failure. Placing an order, moving money, viewing a balance, reading a statement, running a report — each with a target derived from what happens when it fails.
• Measure from the client where possible, since server-side success rate cannot see requests that never arrived.
• Include latency in the SLI. A response that arrives after the user gave up is a failure, so the indicator is "successful and within the latency bound".
• Choose a short measurement window. Monthly availability hides a four-hour outage; per-minute does not. A monthly figure is an accounting convention rather than a user experience.
• State whose availability is included. A third party on the path makes their floor your ceiling unless the design routes around them, and a target that ignores this is fiction.
• Attach an error budget with a pre-agreed consequence, or the target is a number in a document.

Industry example

A brokerage such as Zerodha has journeys whose consequences differ by orders of magnitude: an order placed at the market open has money at risk and a deadline that cannot be retried later, while a statement from three years ago has neither. Giving both the same target means either spending trading-grade money on statements or accepting statement-grade reliability on trading.

The same spread exists in every product with a transactional core and an informational periphery — payments, insurance, logistics, commerce.

Failure scenarios

• One number for the platform, unactionable when missed.
• Per-service targets, all green during a user-visible outage.
• A monthly window, hiding the outages users actually noticed.
• Availability measured without latency, so a degraded-but-responding system scores perfectly.
• Third-party dependencies excluded, making the target unachievable in practice and unfalsifiable on paper.
• No error budget, so the target changes nothing.

Trade-offs

Journey-level measurement requires instrumentation that spans services — distributed tracing, client-side telemetry, or synthetic journeys — which is real engineering work that service-level metrics do not need. And a proliferation of journeys produces a proliferation of targets, which becomes its own management burden.

The mitigation is to define a small number of journeys, perhaps five to eight, chosen by business consequence, and to accept that everything else is measured only at service level. A comprehensive journey catalogue is a worse outcome than a short one that is actually used.

Interview question

"Your platform reports 99.95% availability and a major customer says you were down for an hour yesterday. Both statements are true. Explain how, and tell me what you would measure instead."