Writing SLOs your engineers will actually defend

An objective on CPU utilisation or pod restarts tells you nothing a user would recognise. Start instead from the two or three journeys that define your service - for a payments platform, that might be 'authorisation completes', 'settlement file lands', 'merchant can view a transaction'.

For each journey, define availability as the proportion of attempts that succeeded within an acceptable latency, measured as close to the user as you can get. That single reframing eliminates most of the metrics people argue about and produces numbers a business stakeholder can engage with.

Do not open with a number. Measure current performance for a month, then present it: 'we are at 99.4% on authorisation, which is roughly four hours of failed attempts a month'. The conversation about whether that is acceptable is now grounded, and the target that emerges is one people believe.

Resist 99.99% by default. Each additional nine multiplies engineering cost, and the honest answer for most internal services is that a lower target is entirely fine. An objective nobody intends to fund is worse than none, because it teaches the team that these numbers are decorative.

An objective only becomes real when breaching it changes what happens next. The mechanism is the error budget: the allowable unreliability in the period. While budget remains, ship features. When it is exhausted, reliability work takes priority until the service is back inside its objective.

That policy must be agreed by the product owner in advance, in writing, while everything is calm. Negotiated during an incident, it always loses to the roadmap. Agreed beforehand, it becomes the mechanism that keeps reliability funded - and the reason engineers will defend the objective rather than ignore it.