What it measures

Change Failure Rate measures how often a change that reaches production breaks something badly enough to need intervention. A failure here means a deployment that results in degraded service, an outage, or a defect that forces a rollback, a hotfix, or a fix-forward patch. It is expressed as a percentage: failed deployments divided by total deployments over a window.

It is a stability counterweight to throughput metrics like Deployment Frequency and Lead Time for Changes. High velocity with a high failure rate means you are shipping fast and breaking things often. The metric tells you whether your release process is producing reliable outcomes or just frequent ones.

How to measure it

Define what counts as a failure first, because the number is meaningless without it. The usual rule: a production deployment is a failure if it triggers a rollback, an emergency hotfix, an incident, or a revert within a short window after release. Then compute failures divided by total production deployments over a period, typically a month or a quarter.

The deployment side comes from your pipeline: CI/CD run records, release tags, or deploy events tied to a production environment. The failure side comes from correlating those deploys with rollback commits, revert pull requests, incident tickets, or commits whose messages and timing mark them as fixes for a just-shipped change. Linking a revert or hotfix back to the deploy that caused it is the part most teams get wrong, since it requires matching git history and deploy timing rather than counting tickets by hand.

What it does not tell you

Change Failure Rate tells you that releases broke, not why they broke or whether the broken work mattered. A 5 percent rate across a quarter says nothing about whether the failures clustered in one fragile service, hit your most strategic initiative, or landed in code no customer touches. It counts failure events without weighting them by blast radius, by the initiative they belonged to, or by who carried the cost of the cleanup.

It also rewards caution in misleading ways. A team that ships rarely and trivially can post a clean rate while a team doing hard, high-value work shows a worse one, and the raw percentage makes the second team look weaker. The metric measures motion and its mishaps, not direction: it reads how stable the releases were, not whether the work was the right work or aligned to where the business is trying to go.

That gap is the difference between activity data and Execution Intelligence. Knowing your failure rate is a starting signal. Knowing which initiative the failed changes served, which contributors and which fragile parts of the system they touched, and what the remediation actually cost is what turns a stability number into a decision you can act on.

How InteliG uses it

InteliG computes Change Failure Rate from real git and deployment history, with no manual instrumentation or hand-tagged incident logs. It reads commits, pull requests, and deploy events directly, correlates reverts and hotfixes back to the releases that caused them, and derives the rate from what actually happened in the pipeline.

From there Cognis connects each failure to the initiative the work belonged to, the contributors involved, and the cost of the deployment and its cleanup. That turns a flat percentage into an explanation: which strategic work is failing in production, who is absorbing the remediation, and what it is costing the organization.

Related terms

Mean Time to Recovery (MTTR) — How long it takes to restore service after a production failure.
Deployment Frequency — How often a team ships changes to production.
Execution Intelligence — Reading what an org is actually building and why, connecting code to strategy and cost.