Aspirational and Achievable SLO
The distinction between the reliability a team wishes for and the reliability its current architecture and dependencies can actually deliver.
An SLO set above what the system can achieve is not a target; it is a permanently exhausted error budget and therefore no signal at all. Once a budget is always empty, the policy attached to it is ignored, and the whole mechanism becomes decorative.
Start from measurement, not ambition. Compute the SLI over the last quarter. That number, minus a little, is the achievable SLO. Set it there, and it immediately becomes useful: deviations are meaningful, and the budget genuinely constrains change.
Then treat the aspirational figure as a roadmap item with a cost. Moving from 99.9% to 99.99% requires specific work — removing a single point of failure, automating a failover, eliminating a synchronous dependency — and each item can be estimated and prioritised like anything else.
The related error is setting an SLO tighter than dependencies allow. A service that depends on a platform offering 99.9% cannot promise 99.95% on the synchronous path, no matter how good its own code is. Availability arithmetic sets a ceiling, and an SLO above it is a promise someone else has to keep.