Change failure rate

Use deployments as the denominator

In an illustrative month, a service makes 40 production deployments. Three require an urgent rollback or corrective patch. Under that counting rule, the change failure rate is 3 divided by 40, or 7.5%.

The numerator should count affected deployments, not the number of people paged or tickets opened. One failed release can produce several incident records. Counting each record separately would exaggerate the rate.

Separate release failures from other problems

A network provider outage can disrupt a service without being caused by its deployment. Conversely, a failed deployment may be corrected before it produces a lengthy customer-facing outage.

Define the relationship between a deployment and an intervention. Keep ambiguous cases inspectable. The usefulness of the number depends on consistent classification, especially when the total number of deployments is small.

A rate is not a severity measure

Two teams can have the same failure rate with very different consequences. One might recover from brief regressions quickly, while another causes prolonged disruption with each failed change.

Read the rate alongside recovery time and the impact of the failures. Avoid celebrating a lower percentage that comes only from adding many trivial deployments to the denominator. The aim is dependable delivery, and the underlying incidents are often more informative than a single monthly percentage.