Change Failure Rate measures the share of deployments that fail or need a corrective change. It is the quality counterweight to the speed-focused DORA metrics.
What it measures
Of every deployment in the period, what share went wrong — either because the deployment itself failed, or because it had to be corrected right after.
Where the failure signal comes from
Like Deployment Frequency, this metric reads from one of two sources, and the same organization setting controls both:
Merged pull requests (default) — a merged PR counts as a failure when its title reads like a corrective change. Leanmote matches, case-insensitively and in English and Spanish:
fix,bugfix,hotfix,bug,glitch,parche,correccion,incidente,incidencia. Note thatpatchis not on the list, and that matching is on any part of the title — a PR called "Add prefix handling" containsfixand counts as a corrective change. The denominator is every merged PR in the period.GitHub deployments (opt-in) — a deployment counts as a failure when GitHub reports its state as failure or error. This is the more direct signal of the two: it's the pipeline's own verdict on the release, not an inference from what someone typed in a title. The denominator is every production deployment in the period. For teams measured through a deploy check run, a check that fails, times out, or ends in action required counts as a failure.
If the number looks higher or lower than you expect, open Show details and read what was counted before drawing conclusions.
How Leanmote calculates it
change_failure_rate = (failures / total) * 100
Default source:
failures= merged PRs with a corrective-change title,total= all merged PRs.Deployment source:
failures= production deployments in a failed state,total= all production deployments. If your organization never marks an environment as production, all deployments are counted rather than none.Tracked per team and per repository, so you can isolate hotspots instead of blaming the whole organization.
Show details lists the items behind the numerator — the corrective PRs, or the failed deployments with repository, environment, and deploy time.
Switch to GitHub deployments
Go to Settings → Modules → Performance Delivery and turn on Measure deployments from GitHub (organization owner only; the toggle appears when GitHub is connected with at least one active repository). Deployment Frequency switches over at the same time; Lead Time for Changes and Time to Restore stay merge-based. Enabling it backfills up to a year of deployment history — see Deployment Frequency for the details of the backfill and its progress notice.
How to interpret it
Below 15% is generally considered healthy in DORA's elite-team benchmarks.
Trending up while frequency rises — you may be trading quality for speed. Investigate test coverage and release process.
Spikes after a process change are normal but should normalize within 2–3 cycles. If they don't, roll back the change.
A step change right after switching sources — expected. "PRs that look like fixes" and "deployments that failed" are different populations, so don't read the switch as a regression.
What to do about it
Strengthen pre-merge testing — unit, integration, and contract tests.
Add canary or progressive rollout so failures are caught before full exposure.
On the default source, keep PR titles honest: reserve fix/hotfix wording for actual corrective work so the metric stays meaningful.
On the deployment source, make sure your pipeline reports deployment status back to GitHub — a failed deploy that never updates its state is invisible to the metric.
Pair with Time to Restore — a higher failure rate is more tolerable when recovery is fast.
Related metrics
Deployment Frequency
Mean Time to Recovery
DORA metrics overview