Leadership asks for "five nines" across the platform. Engineering says it is impossible. Design the response.

Reframe the request

"Five nines" is almost never what the business actually wants. 26 seconds of downtime per month is a number chosen for its rhetorical weight, not derived from a cost of unavailability.

The productive question is per-journey: what does an hour of unavailability of this specific capability cost? Checkout and payment authorisation have a large number. The reporting export does not. A single platform-wide target is the wrong shape regardless of the value.

Measure before you commit

Compute the current SLI over the last quarter for each critical journey. That number, minus a little, is the achievable SLO today.

An SLO set above what the architecture can deliver produces a permanently exhausted error budget, which carries no signal, so the attached policy is ignored and the mechanism becomes decorative. Starting from measurement avoids that in the first week.

Show the ceiling arithmetic

Dependencies in series multiply. Ten at 99.9% give 99.0% — seven hours a month. If the platform depends on components offering 99.9%, no amount of local engineering makes the synchronous path 99.99%.

This is not an excuse; it is a design input. It points directly at the work: remove a synchronous dependency, make it asynchronous, add a cached fallback, or accept the ceiling.

Price the next nine

Each nine costs roughly an order of magnitude more and changes the mechanisms.

99.9% — redundancy and competent operations. 99.99% — multi-zone, automated failover, no manual step in recovery; note that 4.4 minutes a month does not allow for paging a human, so this is where automated recovery stops being optional. 99.999% — multi-region active-active, and the change process rather than the architecture usually becomes the constraint.

Present cost per journey against the cost of downtime for that journey. The conversation stops being about ambition and becomes a normal investment decision.

Then make the SLO operational

Tiered targets — 99.95% for checkout, 99.9% for account management, 99.5% for reporting.

An error budget policy agreed in writing before the budget is spent: remaining → ship; exhausted → reliability work takes priority, with a named person who can grant exceptions.

Burn-rate alerting with two windows per severity, so severity follows impact rather than an arbitrary threshold.

Internal SLOs tighter than customer SLAs — typically one nine of headroom — so you react before the contract is at risk.

What a strong answer adds

Saying plainly that an SLO nobody will honour is worse than none, because it teaches the organisation that reliability targets are theatre. The commitment that matters is to the policy, not the number.