Change failure rate

Most engineering leaders know their deployment frequency. Far fewer know what percentage of those deployments are quietly breaking things. Change failure rate measures exactly that: the share of deployments that result in a degraded service, an incident, or a rollback. When this number is invisible, your squad ships faster and faster into instability, and the cost shows up as unplanned work, on-call burnout, and eroded stakeholder trust. This page covers the definition, formula, DORA benchmarks, a real-world example, and concrete steps to bring your change failure rate down.

Key takeaways

• Change failure rate is the percentage of production deployments that result in a service degradation, incident, or rollback. It is one of the four DORA metrics and directly reflects the stability of your delivery process. A high rate signals that your squad is spending significant time on unplanned remediation instead of shipping new value.
• The formula is: Change failure rate = (number of failed deployments / total number of deployments) × 100. According to the 2023 DORA State of DevOps report, elite teams achieve a change failure rate of 5% or less, while low performers see rates above 15%. That gap translates directly into engineering capacity lost to firefighting.
• The most common mistake teams make is conflating a low change failure rate with a low deployment frequency. Some squads reduce deployments to avoid failures, which masks the root cause and slows delivery without improving quality. The goal is frequent, stable deployments, not fewer deployments with the same underlying fragility.
• DevStats tracks change failure rate automatically by connecting to your CI/CD pipeline, Git provider, and incident tooling, with benchmarks against 1,000+ engineering teams. Start a free trial to see your numbers in under two minutes.

Change failure rate definition

Change failure rate is the percentage of software deployments that cause a production failure, requiring a hotfix, rollback, or incident response. It measures the reliability of your delivery process, not the frequency of it.

Technically, it is calculated as: Change failure rate = (failed deployments / total deployments) × 100. A "failed" deployment includes any change that results in a degraded service, a P1/P2 incident, or an emergency rollback. Teams that track all four DORA metrics together get the clearest picture of delivery health, since change failure rate is most meaningful when read alongside deployment frequency and mean time to restore.

From a business perspective, every failed deployment is unplanned work. That work consumes engineering capacity that was budgeted for features, compresses future sprint commitments, and chips away at the reliability reputation your product depends on.

Why change failure rate matters for engineering teams

When squads do not track change failure rate, instability becomes normalized. Incidents feel like random bad luck rather than a signal from a measurable process. Unplanned remediation work accumulates sprint over sprint, and planning accuracy degrades because a significant share of each sprint gets consumed by fires that were not on the board at the start of the week.

For engineering leaders, the stakes are concrete. A high change failure rate compresses your squad's effective throughput, increases on-call load, and creates a cycle where players spend more time fixing than building. It also directly affects stakeholder confidence: repeated production incidents make it harder to defend the team's velocity to product and executive stakeholders.

Change failure rate is one of the four DORA metrics, placing it squarely within the most widely adopted framework for measuring software delivery performance. Measuring it is the first step. What you do with that data, where you tighten code review gates, how you structure deployment batching, which parts of the pipeline need more test coverage, is the engineering leader's decision to make.

How to measure change failure rate

To calculate change failure rate, you need two counts over a defined time window: the number of deployments that triggered a production incident or required a rollback, and the total number of deployments in that same window. Divide the first by the second and multiply by 100. Most teams define "failure" as any deployment that results in a P1 or P2 incident, a hotfix deployment within 24 hours, or a rollback initiated by the on-call engineer.

The data sources you need are your CI/CD pipeline for deployment records, your incident management tool (PagerDuty, OpsGenie, or equivalent) for incident counts, and your Git provider for correlating commits to deployments. Without all three connected, you are likely undercounting failures. DevStats's deploy feature and benchmarks surface this data automatically and compare your rate against industry peers.

Change failure rate in practice: a real example

A VP of Engineering at a 45-person SaaS company noticed that her squad's sprint velocity looked healthy on paper, but the on-call rotation was getting hammered every other week. She pulled three months of deployment and incident data and found a change failure rate of 18%. The failures clustered around a single service that was being touched by four different players with no shared ownership and minimal automated test coverage. That pattern was not visible until the metric was calculated and mapped to specific services.

She made two decisions: she assigned a dedicated owner to that service and added a required integration test step to its deployment pipeline before any change could reach production. After six weeks, the change failure rate for that service dropped to 6%. She measured the result by tracking both the incident rate on that service and the unplanned work percentage in subsequent sprints, which freed up roughly two days of squad capacity per week for planned feature work.

How to improve change failure rate

1. Add automated integration tests to your highest-risk services. Identify which services appear most frequently in incident postmortems. For each one, add integration tests that run in the deployment pipeline before any change reaches production. This catches regressions before they become incidents rather than after.
2. Tighten code review requirements for high-churn files. Review your code review data to find files changed most frequently with the least review coverage. Require at least two reviewers for changes to those files. High churn with light review is one of the strongest leading indicators of future failures.
3. Reduce deployment batch size. Large batches make it harder to isolate which change caused a failure. Smaller, more frequent deployments make rollbacks faster and root-cause analysis easier. If your squad is batching to reduce risk, that is a signal the pipeline needs more confidence, not fewer deployments.
4. Track PR cycle time as a leading indicator. When PR cycle time spikes, changes are sitting in review longer, accumulating merge conflicts and untested combinations. Long cycle times often precede failure rate increases by one to two sprints.
5. Run blameless postmortems and act on the systemic findings. Each incident postmortem should produce at least one process change, not just a fix to the immediate bug. DevStats surfaces the deployment and incident patterns that give postmortems real data to work from, but the engineering leader decides which systemic changes to prioritize.

Change failure rate vs. mean time to restore

Change failure rate and mean time to restore (MTTR) are both DORA stability metrics, but they measure different things: change failure rate measures how often deployments cause failures, while MTTR measures how quickly your squad recovers when they do.

Use change failure rate to diagnose your prevention process and MTTR to diagnose your recovery process. A squad can have a low change failure rate but a high MTTR, meaning failures are rare but painful when they occur.