Metrics and queries for delivery
Metrics and queries for delivery
| Metric | Signals |
|---|---|
| Deployment frequency | How often value reaches users |
| Change failure rate | Proportion of deployments causing a failure |
| Time to recovery | How fast you recover when one does |
| Lead time for changes | Commit to production |
| Deployment duration | Cost of each release |
Frequency and failure rate together
Deployment frequency alone is gameable — deploy more often, achieve nothing. Paired with change failure rate it becomes meaningful: rising frequency with flat failure rate is genuine improvement; rising frequency with rising failure rate is recklessness.
The pairing exists because the two are in tension, and reporting either alone invites optimising it at the other's expense.
Small batches
Frequent deployment tends to reduce risk rather than increase it, because each release contains less change. A smaller change is easier to review, easier to attribute when something breaks, and easier to reverse. That is the counter-intuitive result worth carrying into a scenario question: the team deploying monthly is usually taking more risk per deployment than the team deploying daily.
Recovery over prevention
Time to recovery is often the more actionable target. Failures will happen; halving recovery time is usually cheaper and more reliable than trying to halve failure rate, and the two combine — frequent small deployments with fast rollback produce short outages.
Primary sources