Software Delivery in a Minute
Change Failure Rate
What change failure rate measures, how definitions vary, and why it must pair with other signals.
In one sentence
Change failure rate is the share of deployments that cause a degraded service and require remediation—under a definition your organization must make explicit.
Why it matters
It is a DORA stability signal. Without a clear “failure” definition, teams game the metric by under-reporting incidents or avoiding deploys.
How it works
- Define failure (rollback, hotfix, SEV, customer-impacting defect within N hours).
- Count failed changes over total production changes in the window.
- Review borderline cases with a written rulebook.
- Read alongside deployment frequency and recovery time.
Example
If 50 production deploys occurred and 4 required hotfixes under your policy, change failure rate is 8%. A deploy that caused a brief blip with no remediation may or may not count—document the rule.
What this proves
Change failure rate proves the ratio of changes meeting your failure definition to total counted changes.
What this does not prove
A low rate does not prove high software quality if you barely deploy, or if failures are hidden. A higher rate does not prove a team is careless without context.
Sources
Last reviewed 2026-09-06. Title for citation: Software Delivery in a Minute: Change Failure Rate.