Why our fifth attempt at error budgets worked when the first four did not.

We tried and abandoned SLOs four times before one stuck. Each failure taught us something the textbooks glossed over, so here is the honest retro on what finally made the fifth attempt work.

Attempts one through four

  • Too many. Our first attempt had an SLO for everything. Nobody could tell which mattered, so none did.
  • Too abstract. The second measured internal metrics no user would ever feel.
  • No teeth. The third had targets but no agreed response when we missed them.
  • No owner. The fourth belonged to everyone, which meant no one maintained it.

What changed on the fifth

We picked exactly one SLO for the service — checkout success rate over thirty days — that mapped directly to something a customer feels. It had a clear owner, a pre-agreed response when the budget burned, and nothing else competing for attention.

slo "checkout success":
  sli: rate(success) / rate(total)
  target: 99.9% over 30d
  owner: checkout-team

The lesson

The SLO stuck because it was small, felt by users, owned by someone, and connected to a decision. Every earlier version failed one of those tests. Reliability programs do not fail because the math is hard; they fail because the scope is too big and the ownership too vague.