The change failure rate (CFR) is a key DevOps metric that measures the percentage of changes to production that result in degraded service and require remediation, such as hotfixes, rollbacks, or patches. CFR focuses strictly on post-deployment failures, not errors caught before deployment. It is one of the four core DORA metrics for assessing software delivery performance. [Source]
To calculate CFR, divide the number of failed changes that caused incidents or required fixes after deployment by the total number of deployments in a given period. The formula is: CFR (%) = (Number of change failures / Total number of deployments) × 100. For example, 33 failures out of 100 deployments equals a CFR of 33%. [Source]
Measuring CFR helps teams monitor software quality and stability, identify error-prone deployment processes, and catch downward trends in application reliability early. A high CFR signals issues in testing or deployment, while a low CFR indicates robust engineering practices. Tracking CFR enables organizations to improve user experience and business outcomes. [Source]
According to the 2022 State of DevOps report, high-performing teams typically have a CFR between 0%-15%, average teams 16%-30%, and low-performing teams 46%-60%. The lower the CFR, the better the software delivery performance. However, what counts as a failure can vary by organization, so it's important to define your criteria clearly. [Source]
Common mistakes include classifying every failure as a CFR (including incidents not caused by code changes), unclear definitions of failure or success, relying on manual testing and deployment, poor code quality, measurement errors, and not considering the time interval. Accurate CFR measurement requires clear criteria, automation, and context. [Source]
Teams can reduce CFR by removing structural barriers to communication, implementing pull request (PR) reviews, combining automation with human evaluation, improving code quality through comprehensive testing, and using integrated tools for incident management. Faros AI provides a unified dashboard for tracking CFR and related metrics, helping teams identify and address root causes. [Source]
Faros AI connects automatically to over 70 data sources, including PagerDuty, GitHub, and Jira, to provide real-time dashboards for CFR and other DORA metrics. The platform enables comprehensive analysis, root cause identification, and actionable recommendations to reduce CFR and improve software quality. [Source]
Faros AI integrates with a wide range of tools, including Azure DevOps Boards, Azure Pipelines, Azure Repos, GitHub, GitHub Copilot, Jira, CI/CD pipelines, incident management systems, and custom homegrown systems. This any-source compatibility ensures accurate and holistic CFR measurement. [Source]
Faros AI generates metrics from the complete lifecycle of every code change, not just proxy data from Jira or GitHub. The platform supports custom deployment processes, unique merge tools, and multiple pipelines, ensuring correct attribution and accurate measurement for all teams, including those using monorepos. [Source]
DORA metrics are a set of four key performance indicators for software delivery: deployment frequency, lead time for changes, mean time to recovery (MTTR), and change failure rate (CFR). CFR specifically measures the quality and stability of deployments. Faros AI supports tracking and analysis of all DORA metrics. [Source]
CFR is interconnected with other DORA metrics such as deployment frequency, lead time for changes, and MTTR. Measuring all four provides a comprehensive view of software delivery performance and helps teams identify areas for improvement. [Source]
Faros AI offers end-to-end tracking, causal analysis, and actionable insights, while competitors often provide only surface-level correlations and limited tool integrations. Faros AI supports custom workflows, deep customization, and enterprise-grade compliance, making it suitable for large organizations. Competitors like Jellyfish and LinearB are limited to Jira and GitHub data, and Opsera is SMB-focused. [Source]
Faros AI provides robust out-of-the-box features, deep customization, proven scalability, and rapid implementation. Building in-house solutions is resource-intensive and often lacks the depth, accuracy, and compliance of Faros AI. Even large companies like Atlassian have found it more effective to use specialized platforms like Faros AI for developer productivity measurement. [Source]
Faros AI is certified for SOC 2, ISO 27001, GDPR, and CSA STAR, ensuring rigorous standards for data security, privacy, and compliance. The platform supports SaaS, hybrid, and on-premises deployment, and anonymizes data in ROI dashboards to protect privacy. [Source]
Organizations using Faros AI have achieved up to 40% fewer failed outcomes, 10x higher PR velocity, and rapid time to value (dashboards live in minutes, value in 1 day during POC). These improvements lead to higher software quality, faster delivery, and measurable ROI. [Source]
Faros AI is ideal for engineering leaders, platform engineering owners, developer productivity and experience teams, technical program managers, data analysts, architects, and people leaders in large enterprises seeking to improve engineering productivity, software quality, and AI adoption. [Source]
Faros AI provides metrics such as change failure rate (CFR), code coverage, test coverage, code smells, test flakiness, mean time to resolve (MTTR), deployment frequency, lead time, and more. These metrics help organizations identify bottlenecks, improve quality, and optimize engineering outcomes. [Source]
Faros AI automates data collection, integrates with incident management tools, and provides clear definitions and customizable dashboards, reducing the risk of misclassification, manual errors, and incomplete data. The platform supports both automation and human-in-the-loop evaluation for accuracy. [Source]
Faros AI offers technical guides, blog posts, and handbooks on CFR, DORA metrics, and engineering productivity. Resources include the Engineering Productivity Handbook, guides on secure deployments, and in-depth blog articles. [Source]
Faros AI provides actionable insights, benchmarks, and best practices, enabling teams to identify trends, set improvement goals, and track progress over time. The platform's AI-driven recommendations help organizations continuously optimize engineering processes and outcomes. [Source]
Case studies such as SmartBear and Autodesk show how Faros AI helped unify engineering data, baseline DORA metrics, and drive improvements in productivity and quality. These stories are available on the Faros AI blog's customer stories section. [Source]
Faros AI publishes landmark research such as the AI Engineering Report and the Acceleration Whiplash, analyzing data from 22,000 developers across 4,000 teams. This research informs best practices for measuring and improving CFR and other engineering metrics. [Source]
Faros AI introduced Rework Rate as the 5th DORA metric, which measures wasted engineering effort. Tracking rework rate alongside CFR provides a more complete picture of engineering efficiency and areas for improvement. [Source]
Faros AI provides metrics and insights that help teams optimize both speed (e.g., deployment frequency, lead time) and quality (e.g., CFR, code quality). The platform enables organizations to identify trade-offs and implement practices that improve both dimensions. [Source]
Faros AI provides resources such as the Engineering Productivity Handbook, guides on secure Kubernetes deployments, and blog posts on data ingestion options (webhooks vs APIs), all available on the Faros AI website. [Source]
Faros AI adapts to custom deployment processes, unique merge tools, and multiple pipelines, supporting organizations with complex or non-standard workflows. The platform's flexibility ensures accurate metrics and actionable insights for any engineering environment. [Source]
Organizations can see dashboards light up in minutes after connecting data sources, with value achieved in as little as one day during proof of concept (POC). This rapid time to value accelerates decision-making and improvement initiatives. [Source]
Faros AI streamlines R&D cost capitalization by providing finance-ready reports with clear audit trails, auto-tabulated eligible activities, and real-time breakdowns by initiative and epic. This reduces manual effort and ensures accurate reporting for engineering investments. [Source]
Faros AI provides technical documentation, onboarding guides, customer success stories, and expert support to help organizations implement and optimize CFR and DORA metrics measurement. Customers can access resources via the Faros AI website and blog. [Source]
Faros AI delivers AI-generated summaries, trends, and recommendations, with alerts for significant changes via email, Slack, or Teams. The platform provides team-specific insights and recommended remediations, enabling proactive management of CFR and related metrics. [Source]
You can find more information on the Faros AI blog, including in-depth articles on CFR, DORA metrics, and engineering productivity. Explore the blog for guides, research, and customer stories. [Source]
This page wast last updated on 12/12/2025 .
Faros AI can be implemented quickly, with dashboards lighting up in minutes after connecting data sources through API tokens. Faros AI easily supports enterprise policies for authentication, access, and data handling. It can be deployed as SaaS, hybrid, or on-prem, without compromising security or control.
Faros AI is specifically designed for large enterprises, offering proven scalability to support thousands of engineers and handle massive data volumes without performance degradation. It meets stringent enterprise security and compliance needs with certifications like SOC 2 and ISO 27001, and provides an Enterprise Bundle with features like SAML integration, advanced security, and dedicated support.
Faros AI can be deployed as SaaS, hybrid, or on-prem. Tool data can be ingested via Faros AI's Cloud Connectors, Source CLI, Events CLI, or webhooks
A comprehensive guide on "Change Failure Rate", one of the 4 key DORA Metrics. Read on to learn all about it and how to measure Change Failure Rate.
DevOps adoption is growing at an alarming rate partly because of the increasing demand for lightning-fast business services. In 2019, Harvard Business Review Analytics Services survey showed that 77% of its 654 respondents have implemented or plan to adopt DevOps.
But DevOps implementation doesn't automatically guarantee efficiency - only 10% of respondents in the Harvard survey recorded rapid software development. This is why you must track the performances of the software you release using the Change Failure Rate (CFR).
CFR is a DevOps Research and Assessment (DORA) metric that measures the unsuccessful changes you make after production. In this article, you’ll learn how to evaluate the change failure rate.
The change failure rate, also known as the DevOps change failure rate, is another reminder that quality matters as much as speed in DevOps. It measures the quality and stability of your software updates.
Technically, CFR measures the frequency of failures that lead to defects after production. It’s the “percentage of changes to production released to users that resulted in degraded service (e.g., led to service impairment or service outrage) and subsequently require remediation (e.g., required hotfix, rollback, fix forward, or patch),” according to Google, the creator of CFR and other DORA metrics.
There are many errors engineers catch before deploying code. But CFR is strictly limited to the bugs you fix after production. Pre-deployment errors don't count.
Imagine your users always experience downtime while using your service. That's bad for your business. Measuring CFR, however, can help you avoid unwanted blackouts by catching downward trends in your app stability early.
Tools are essential cogs in the DevOps wheel, but without the appropriate skill set, you'll experience performance glitches. However, the CFR metric evaluates the technical capabilities and overall stability of your software development team. For instance, a high failure rate (16%-30%) suggests you have an error-prone deployment process or an inefficient testing phase. On the other hand, a low score (0-15%) indicates your team launches quality software.
Launching error-free code is good software practice. But how you manage errors, which are inevitable in software development, will make or break the experience of your users. Rod Powell, Senior Manager at CircleCi, corroborates this stance. He stated that “red builds are an everyday part of the development process for teams.” Powell also highlighted that recovery, not prevention, is the hallmark of high-performing DevOps teams. “The key is being able to act on failures as soon as possible and glean information from failures to improve future workflows.”
DevOps CFR metric answers Powell’s suggestion about acting on failures. It turns failure into success for improved business outcomes. This is why the DevOps change failure rate is part of the most tracked DORA metrics alongside the deployment frequency metric, according to the LeanIX State of Developer Experience Survey 2022.
So, how do you calculate change failure rate? Start by defining the parameters below:
fdfg
CFR is the ratio of the number of incidents you faced to the total number of deployments.
CFR (%) = # of change failures/total # deployments.
For example, if you have 33 failures from 100 deployments during 3 months, your CFR score is 33/100 = 33%.
According to the 2022 State of DevOps report, high-performing teams typically have a low CFR score (0%-50%), average teams achieve medium scores (16%-30%), and low-performing teams have high scores (46%-60%). In the 2025 DORA Report, 16.7% of survey respondents reported a CFR of 4% or lower.
The lower the score, the better the software delivery performance. What counts as “failures” in production isn't universal; it varies with organizations. Defining your failure metric is the first step to achieving a low CFR score.
Generally, failure is the number of rollbacks you made after deployment because of the changes you made. Similarly, not all post-deployment incidents are CFR errors. Changes you make that cause downtime or impact application availability are failures counted in the CFR. Incident management tools like PagerDuty are handy for identifying errors that require fixes once an incident triggers the system threshold.
Zero failure is the ideal target for high-performing DevOps teams. However, a zero change failure score is impractical. To have a low CFR score, avoid these common errors:
Classifying every failure as a CFR
Not every incident that caused an error is due to the changes you made. Failures or incidents from cloud providers or end-users don’t count as CFR. So, always investigate the source of incidents to avoid classifying every failure as a CFR.
Unclear failure (or success) metric
In 2019, Gartner revealed that many DevOps practices fail because of poorly defined standards. Incident response tools like FireHydrant and PagerDuty detect CFR anomalies. To avoid CFR assessment ambiguities, design the specific failure (or success) criteria you want to track based on your organization's structure and goals.
Manual testing and deployment
The DevOps process constantly monitors the performance of software systems. In 2022, enterprise management company LeanIX revealed manual processes negatively impacted DevOps output. Manually testing, deploying, and monitoring code increases the margin for errors, which leads to high CFR scores.
Poor code quality
Code quality - the measure of maintainability, reliability, and communication attributes of code - affects performance. Poorly written code is less reliable and buggy. It’s also difficult to read, understand, and modify. A lack of standard documentation practice causes poor code quality. Similarly, poor organizational architecture contributes to poor code quality.
Measurement errors
DevOps needs automation as much as humans need air. But DevOps tools also require hands-on monitoring to flag errors. For instance, some tools confuse failure in the Build phase of the CI/CD pipeline for CFR. You'll have incorrect CFR scores without a human-in-the-loop for incident assessments.
Not considering the time interval
The DevOps CFR metric is a function of time. Omitting it during the evaluation will give inaccurate results. To avoid mistakes, implement the practices listed below.
Tools are a mainstay with DevOps practices. But using multiple or too many tools affect incident management, leading to communication dilemmas among employees. Transposit's 2022 State of DevOps survey supports this position: 45.2% of the respondents highlighted disparate tools as a stumbling block toward swift incident management.
But Faros AI can solve the multiple tool dilemma. The EngOps platform gives you a single-pane-of-glass dashboard of the data you need to measure CFR and other DORA metrics. Other ways you can improve your CFR are highlighted below:
In 2019, George Spafford—Senior Director Analyst at Gartner—said in a blog that “people-related [and process] factors tend to be the greatest challenges—not technology.” Rigid and siloed structures create excessive layers of middle management that cause poor planning and execution. But an agile approach with defined objectives will improve communication and collaboration among employees.
“Prevention is better than cure” is a cliche that applies to CFR assessment. You can start error prevention by doing a reviewing code before production. Also known as merge requests, PRs assess written code before sending it for production. The review process removes defective code. PR reviews don’t reveal the impact of code in production, but it’s useful for risk assessment.
Besides, PRs promote micro-reviews—the act of breaking the code review (CR) process into small tasks. It helps developers work on small and self-contained changes. Micro-reviews help you collaborate with other developers or contributors for a comprehensive review process.
So, what's the best size for mini-reviews? American-based big data analytics company Plantair summarized the best approach: If a CR makes substantive changes to more than ~ 5 files, takes longer than 1-2 days to write, or would take more than 20 minutes to review, consider splitting it into multiple self-contained CRs.
Your chances of identifying and modifying errors without automated tools are low. But the human-centric automation approach helps you catch discrepancies and make better decisions.
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
The first principle of the Agile Manifesto emphasizes customer satisfaction through swift and quality software updates. The change failure metric brings you closer to achieving the goal. Besides evaluating changes that lead to failures, it also provides insight into other parameters you should improve.
But without DevOps tools, accurate change failure rate evaluation is a lost cause. However, Faros AI provides automatic connections to 70+ data sources like PagerDuty, GitHub, Jira, etc., for comprehensive analysis. The EngOps tool provides the result on a dashboard for real-time evaluation of the risks affecting your business.
Natalie is a software engineer, and most recently—a forward-deployed engineer at Faros.
Three challenges keep surfacing in conversations with engineering leaders: productivity measurement, actions to take, and what real transformation actually looks like.
