Change Failure Rate

Frequency only counts if you are not breaking things.

Deploys in window

Deploys that caused incident, hotfix, or rollback

Window length in days (optional)

Calculate Reset Copy result

How this is calculated

failed_deploys / total_deploys, shown as a percentage.

Count a deploy as failed if it required any of the following inside the same window: a rollback, a hotfix within 24 hours, or a user-facing incident attributed to the change.

Tiers

Rate	Tier
0 to 15%	Elite / High
16 to 30%	Medium
31 to 45%	Low
> 45%	Reassess

Why this matters

Deploy frequency without change failure rate is half a picture. A team that ships 50 times a week but breaks production on 30 of them is not a high performer. It is a team taking on risk that will eventually take the site down at the wrong moment.

The two numbers work together. Frequency says how fast your team learns. Failure rate says whether the learning is working. Drive one without watching the other and you end up with either a slow team that never breaks anything, or a fast team that always does.

What to do next

• If your rate is above 30%, look at the last five failed deploys. Most teams find the same cause repeats. Fix the cause, not the symptom.
• If your rate is very low and your deploy frequency is also low, you are probably being careful because you cannot recover fast. Invest in rollback and observability, then raise frequency.
• Define “failed deploy” in writing before running this next month. Without a shared definition, the number drifts.