Change failure rate is the proportion of software deployments that cause a failure requiring remediation, rollback, or another corrective action. Track it across environments to reveal where changes become unsafe and whether failures reach users. section 3.4.3
Measure change failure rate as part of an environment-by-environment delivery view:
- Count breaking changes in development, where failures are expected and provide feedback. section 3.4.3
- Follow failures through quality assurance, preview, and production environments. section 3.4.3
- Aim for nearly all failures in development, a few in QA, and none from preview onward. section 3.4.3
- Pair the lagging metric with code quality violations, test coverage, automated-test ratios, and rollback results to find earlier warning signs. section 10.1.2
Epetech’s measurement pattern
Epetech treated lower production change failure rate as a reliability goal because it reduced downtime and strengthened user trust. It examined code quality, test coverage, manual-versus-automated testing, and whether faulty deployments were rolled back. Regular review of these indicators connected platform investment to operational reliability and business goals. section 10.1.2 section 10.7.1
Figure 10.2 Key leading metrics used by Epetech to understand and use the DORA lagging metrics
Use the leading-metrics view to relate change failure rate to deployment automation, testing, code quality, and other early signals. section 10.1.2
