Change failure rate is the share of deployments that cause a failure in production. Measured from a checkbox ticked after an incident review it reflects diligence; derived from correlated incidents a human confirms, it reflects actual failure.
Change failure rate is the percentage of production deployments that cause a failure needing remediation, such as a hotfix, a rollback or a patch. It is one of the four DORA keys and, with time to restore service, one of its two stability measures. The formula is failed deployments divided by total deployments over the same period.
Over a period, count the production deployments, and count how many of them led to a failure that needed remediation. Divide the second by the first. Do it per service and per team as well as overall, because one service carrying the risk is invisible in the total.
Decide it once, write it down, and keep to it.
When change failure rate comes from a field somebody ticks after the incident review, it measures how diligently people fill in the field, not how often changes fail. In the org ArcRelease models against, that checkbox-derived figure starts at 13.8%. Derived from correlated incidents instead, it lands at 7.9%.
ArcRelease counts a deployment as a failure when an incident correlates to it inside its blast-radius window and a human confirms the link. That makes the rate a measurement of failure rather than of process compliance.
Counting only declared incidents and missing the quiet hotfixes. Counting each incident rather than each failed deployment. Using different denominators from one report to the next. Letting teams choose their own definition of failure, then comparing them.
The levers are mostly about making each change smaller and better understood before it ships: small batch sizes, feature flags, canary or progressive rollout, automated checks before the release, and knowing what each release depends on.
Both the 13.8% and 7.9% figures are modelled for one fictional org, not an industry benchmark. ArcRelease does not print benchmarks it does not have.
Failed production deployments divided by total production deployments for the same period, expressed as a percentage. A deployment is failed if it needed remediation: a rollback, a hotfix or a patch.
There is no universal number. DORA's research bands teams by performance, and the thresholds are revised between reports, so check the current report for benchmarks. Within your own organisation, track each service against its own history, and read the rate beside deployment frequency.
No. Defect rate counts bugs. Change failure rate counts deployments that caused a production failure needing remediation. A release can contain defects and not fail in production, and a failure can come from configuration or a dependency rather than a code defect.
Yes, in the usual DORA definition: a deployment that has to be rolled back, or repaired with a hotfix, failed. A planned, deliberate rollback in a progressive rollout is a judgement call; decide it once and apply it consistently.
Continuously, with a rolling window long enough to hold a meaningful number of deployments, for example the last 30 or 90 days. A team that deploys once a month cannot read much from a weekly figure.
They are the two stability keys: change failure rate says how often a deployment fails, time to restore says how long a failure lasts. A team can lower its impact either by failing less often or by recovering faster, and the two are worth reading together.
Tell us about your release process. Connect your stack in ten minutes, run a Gaja preflight on a real release, and see the reasons behind the verdict.
Free plan · ten minute setup · we reply in one to two business days