Documentation menu
Change failure rate
What it is
Change failure rate is one of the four DORA metrics. It measures the share of deployments to production that cause a failure and need remediation: a hotfix, a patch or a rollback. It is a measure of the quality and stability of your releases.
Reading it
The rate should be as close to zero as you can get it; high-performing teams stay under 15%. A rate above that means the team spends a growing part of its time repairing what it just shipped, which also shows up as longer time to restore and lower deployment frequency. Code review practice, test coverage and small changes are the usual levers.
Performance tiers
| Tier | Change failure rate |
|---|---|
| Elite | 0 to 15% |
| High | 15 to 30% |
| Medium | 30 to 46% |
| Low | 46 to 60% |
In Agile Analytics
Nobody labels deployments as failed by hand, so Agile Analytics detects failures in two ways:
- Hotfixes and reverts: a merged merge request whose branch or title marks it as a hotfix or revert repairs the last production deployment of its repository before it was opened. That deployment counts as failed. Ordinary
fix/branches are not counted, because in most teams they are routine bug work waiting for a release. - SLO alerts: when a repository is linked to a service on the Error budgets page, a production deployment that is followed within an hour by a fast-burn SLO alert on that service counts as failed.
In the health score, the change failure rate only counts when failures can be detected at all: a repository linked to an SLO, or a hotfix or revert in the last year. Otherwise it is left out instead of scoring a flattering zero.
