Change failure rate

This post was updated on 26 June 2025 to address changes to Port’s Experiences features, add new competitors, and discuss new developments in platform engineering. Port updates posts regularly to provide the highest-quality information possible to our readers.

The DevOps Research and Assessment (DORA) framework includes four metrics that measure software development teams’ throughput and stability. One key indicator is the change failure rate metric, which tracks the number of production deployments that fail within a given period. 

We’ll discuss below how to calculate change failure rate, how to determine which commits should count as failures, and ways you can reduce them with some best practices.

What is change failure rate?

Your change failure rate (CFR) is an important health metric for your website or application’s stability that can either increase or decrease over a given period.

To calculate your CFR, consider two factors: 

• Your total number of production deployments or releases in a given period.
• The number of deployments that caused failures and bugs, requiring rollbacks or hotfixes after initial deployment.
  

These insights are useful for site reliability engineers (SREs), who manage incidents, and developers engaged in continuous improvement. Both teams can use this metric to direct their collaboration and increase your website’s stability and reliability.

A higher CFR typically indicates that many of your deployments cause failures that require immediate fixes. A lower CFR shows that fewer deployments cause failures, indicating more stable and reliable releases. 

Why is measuring change failure rate important?

Reliable websites play a significant role in providing a good customer experience. Users want websites that quickly and adequately support them, such as making a purchase and finding the information they need.

Measuring your CFR is important because it creates a tangible definition of what a reliable website looks like. Failed changes reduce the quality and reliability of your website, making it difficult for users to accomplish their tasks. 

In e-commerce, a “sticky” website, or a website with many returning users, can: 

• Cut average customer acquisition costs
• Increase average purchase size per customer
• Drive more revenue from e-commerce purchases
• Boost new promoter score (NPS)

Calculating your change failure rate is a great way to build your case for greater organizational change because of its purpose as a health indicator. If your website is frequently down, you can point to this metric as a quantifier when representing the issue to your leadership team. It can also be a benchmark for measuring your success once you experiment with solutions. 

Moreover, if your organization is already measuring your deployment frequency, CFR can be a great complementary metric that helps you balance the impact of more changes to your production environment. 

How to calculate change failure rate

Before measuring CFR, define what counts as a failure based on your organization’s standards and the services you control. For instance, issues that result from third-party cloud providers don’t count as failures for your organization. 

You can track failures by monitoring:

• Failed deployments from continuous integration and continuous delivery/deployment (CI/CD) tools 
• Alerts and incidents from observability or incident management tools
• Ticketing systems
• Deployments with tags like “hotfix” or “rollback”

You might also include standards failures. For example, if your team has defined a standard to update all dependencies promptly, delays could qualify as failures. If you aren’t already measuring standards based on industry benchmarks or internal goals, a good place to start is to define them so your CFR is as comprehensive a measurement as possible.

After failure qualification, determine the period to measure your performance, such as monthly or quarterly. Conducting CFR calculations this way provides a complete and more granular picture across your sprints.

To more accurately track CFR, gather as much information about each release and any subsequent hotfixes. For instance, if a deployment causes four incidents and one of the hotfixes fails, you need a second hotfix. This equates to five failures across six deployments: 

• One initial deployment
• Four hotfixes 
• One final hotfix 

In our example, we had five total failures and six deployments during our given period. If this were to continue for a month, the resulting CFR would be 83%, which is quite high.

What is a good change failure rate? 

According to DORA, a good CFR falls between 0% and 15%. Elite performers have a CFR below 5%, which means they can deploy reliable and stable changes very frequently.

However, CFR is just one of the four DORA metrics, which also include deployment frequency, change lead time, and mean time to recovery (MTTR). To gain a complete picture of your software development performance, you must consider all four metrics in concert. 

Here’s how a lower CFR influences the other three metrics: 

• Deployment frequency: Lower CFR reduces the time spent fixing issues and rolling back changes. By minimizing failures, teams can increase the frequency of their deployments.
• Lead time for changes: Lower CFR minimizes the number of disruptions and delays caused by change failures. Teams accelerate the process from code commit to production, cutting lead time.
• MTTR: A low CFR equates to fewer failures, but when issues like service outages happen, high-performing incident teams fix them quickly, ensuring that systems run as intended.

What are effective strategies to improve change failure rate?

Measuring CFR is just the first step. Once you’ve collected this data, you can determine where to make changes and institute standards to avoid failures.

There are multiple approaches to improve your CFR, such as:

• Automating code testing: Reduces the risk of human error from manual tests and accelerates issue identification. Automated testing prevents faulty code from moving into production.  
• Automating deployment: Abstracts away the more complex aspects of your deployment process, which protects it from human error and confirms that each deployment follows your best practices.
• Implementing engineering standards: Unify development teams around a set of research-based expectations for high-quality software. Setting and raising standards elevate communication between teams, developers, and managers by guiding what counts as acceptable code for deployment. 
• Employing feature flags: Release code changes to a small and specific number of users, rather than the entire user base. Teams can identify and fix failures faster without rolling back the entire deployment, limiting the impact of bad code.
• Prioritizing smaller, more frequent deployments: Pinpoint issues faster and let teams roll them back quickly. These smaller releases prevent widespread problems and accelerate innovation. 
• Implementing an open internal developer portal: Using an internal developer portal like Port makes it easy for engineering managers and developers to improve CFR. Port centralizes key deployment data, provides standards management, and includes self-service actions in one centralized location, letting teams spot and fix issues quickly.
• Shifting testing left spots issues earlier in the software development life cycle (SDLC), eliminating failures later on in the process. 

Use Port’s internal developer portal to track your change failure rate

Port’s IDP unifies all of the data you need to measure your CFR. The portal contains:

• A service catalog, complete with a graphical depiction of your dependencies and the health and status of your services, makes it easy to determine what is and isn’t a failure.

• Scorecards to enforce your engineering standards and track teams’ compliance. You can take corrective action when standards are not met, and automatically trigger alerts to resolve issues faster and meet production readiness requirements. 

Port centralizes the data you need to calculate CFR. Teams can take action directly within the portal to track deployments and rollbacks, refine standards, and more. 

Port’s flexible data model makes building custom metrics easy because it contains data about your company’s priorities and specific domain language. 

Explore Port’s live demo to see how our IDP can lower your CFR.