An internal platform team runs an authentication service consumed by 40 product teams. It achieves about 99.99% availability and publishes an SLO of 99.9%. Product teams complain the published number forces them to build fallbacks they do not need. What did the platform team buy with that gap, and what does it cost whom?

What is gained, quantified

Headroom to change things. A published 99.9% gives the platform about 43 minutes of budget a month; achieving 99.99% means it is spending about 4. The difference is roughly 39 minutes a month of permitted disruption, and that is what pays for migrations, dependency upgrades, failover tests and the occasional bad deployment without any consumer being entitled to complain.

It also buys a correct planning assumption downstream. Consumers design against the published number, so when the platform does have a bad month, nothing downstream was built on an assumption that just broke. Publishing the achieved figure would make every consumer's design depend on the platform never regressing.

And it buys honesty about the chain. Forty teams depending on a service they believe is 99.99% available will each compute their own availability using that figure. If the platform publishes what it hopes rather than what it commits to, those 40 calculations are all wrong in the same direction.

What is paid, and by whom

The consumers pay, in fallback code they mostly do not need. Each of 40 teams building a cache, a degraded mode or a retry path against a 99.9% dependency is 40 implementations of similar machinery, most of which will never execute. That is real engineering cost, real complexity on the critical path, and real untested code — a fallback that never fires in production is untested code in the request path, which is its own reliability risk.

The platform team pays nothing directly, which is exactly why the gap tends to widen over time. The incentive on a platform team is always to publish conservatively.

There is also a trust cost. Consumers who observe 99.99% and are told 99.9% will design against the observed number anyway, which returns the situation to where publishing the achieved figure would have put it, with the added problem that nobody says so out loud.

When the cost becomes visible

At the first real platform incident, in two ways. Consumers who built fallbacks find they do not work, because they were written against a scenario nobody rehearsed. Consumers who quietly designed against the observed 99.99% find they have no fallback at all. The published SLO's value depends entirely on whether anyone believed it, and that is discovered during the incident.

How to keep the option to reverse

Publish two numbers and label them. The commitment — the figure consumers may design against and the one the platform's error-budget policy is enforced on — and the recent achieved figure, as information. The gap is then visible and arguable rather than hidden.

Then make the fallback a platform concern. If 40 teams need the same degraded behaviour, the platform should supply it: a client library with the cache and the degraded path built in, tested by the platform team, exercised in the platform's own game days. One tested implementation instead of 40 untested ones is the change that resolves the complaint without weakening the commitment.

And negotiate the gap rather than setting it. A consumer whose journey genuinely needs more can ask for a higher tier, and the platform can quote what that costs — more capacity, more replicas, tighter change control. That turns an argument about a number into a conversation about who pays for headroom.

When the gap should be closed

When the platform's dependency chain makes the published figure meaningless. If consumers already depend on 4 other services at 99.9%, their journey availability is about 99.6% regardless of what authentication publishes, and the published gap is protecting a decimal place nobody can observe. Check where the published number actually sits in the chain before defending it.

Common weak answers

• "Publish what you achieve." It removes the headroom that pays for change, and the first planned migration becomes an SLO breach.
• "Teams should not need fallbacks for internal services." This is how a single internal dependency becomes a company-wide single point of failure, which is the most common shape of a total outage.
• "Set the SLO to what the business needs." The business needs the journey to work; the platform SLO is one input. Without the chain arithmetic, that sentence cannot be turned into a number.