Change Failure Rate
The proportion of deployments that cause a production failure requiring remediation, and the DORA metric that keeps the others honest.
Deployment frequency and lead time can be improved by shipping carelessly. Change failure rate is the counterweight, and reading it alongside the other three is what makes the set meaningful rather than gameable.
The four: deployment frequency and lead time for change measure throughput; change failure rate and time to restore service measure stability. The research finding that made them influential is that throughput and stability rise together — high performers deploy more often and fail less — which contradicts the intuition that speed trades against safety.
The mechanism behind that correlation is small batches. Frequent small deployments are individually less risky, easier to verify, and faster to diagnose and revert.
Two cautions in using them:
They are team-level improvement metrics, not individual performance metrics. Used for comparison between teams or in performance reviews, they are gamed immediately and the data becomes worthless.
They measure delivery capability, not value. A team can excel on all four while building the wrong thing. They belong alongside outcome measures, not instead of them.
The practices that move change failure rate: progressive delivery, automated testing, trunk-based development, small batches, and — for time to restore — fast rollback and good observability.