What Are DORA Metrics and How Do They Work

Think of the DORA metrics as the four most important gauges on your software delivery dashboard. They tell you, in no uncertain terms, just how fast and reliably your engineering engine is running. These aren’t just random numbers; they were developed by Google’s DevOps Research and Assessment (DORA) team after years of research, giving you a clear, data-driven way to see how well you’re delivering value.

Understanding DORA Metrics: A Health Check for Your Team

If your software delivery process were a high-performance car, you’d never drive it without a dashboard. The DORA metrics are that dashboard. They’re not just abstract figures; they are proven indicators of what high-performing teams actually do, based on extensive research across thousands of organizations.

These metrics help you cut through gut feelings and subjective opinions. They provide a common, standard language for talking about—and improving—engineering performance. Ultimately, they help answer the one question every leader has: “Are we delivering value effectively?”

The Two Sides of Performance: Speed and Stability

The four DORA metrics are perfectly balanced across two crucial categories that every engineering leader obsesses over: throughput and stability. One side measures how quickly you can ship, while the other measures how solid your work is when it gets there.

• Speed Metrics: These focus on your team’s velocity and overall efficiency.
• Stability Metrics: These track the quality and reliability of what you release.

Here’s a quick breakdown to see how they fit together.

The Four DORA Metrics at a Glance

Category	Metric Name	What It Measures
Speed	Deployment Frequency	How often your team successfully releases to production.
Speed	Lead Time for Changes	The time it takes for a commit to get into production.
Stability	Change Failure Rate	The percentage of deployments that cause a production failure.
Stability	Time to Restore Service	How long it takes to recover from a production failure.

By tracking both speed and stability, you sidestep the classic engineering trap of chasing velocity at the expense of quality. Getting a handle on these foundational ideas is a great start, and you can learn even more about software engineering productivity metrics to get a fuller picture of what drives elite performance.

How Fast Are We? Measuring Speed with Deployment Frequency and Lead Time

To get a handle on your team’s true speed, the first two DORA metrics are where you need to look. Think of Deployment Frequency and Lead Time for Changes as the speedometers for your entire software delivery process.

They aren’t just about going fast for the sake of it. These metrics reveal how efficient, automated, and confident your team is. Let’s dig into what each one really tells you.

Deployment Frequency: The Heartbeat of Your Delivery Pipeline

Deployment Frequency is simple on the surface: how often do you successfully ship code to production? But it’s so much more than just a number. It’s a direct reflection of your team’s confidence and the health of your pipeline.

High-performing teams often deploy multiple times a day. They can do this because their processes are reliable, predictable, and almost entirely automated.

A high deployment frequency usually means:

• You’re making small, safe changes. Instead of massive, risky releases, your team is shipping in small, manageable chunks that are easier to test and review.
• Your automation is solid. A well-oiled CI/CD pipeline is handling the grunt work, from running automated tests to pushing code live.
• Your developers are confident. They trust the system and aren’t afraid that their changes will bring everything crashing down.

On the other hand, if you’re only deploying once a month (or even less), it’s a big red flag. It usually points to serious bottlenecks like manual testing, bureaucratic approval gates, or a deep-seated fear of breaking things.

Lead Time for Changes: From Code Commit to Customer Value

Lead Time for Changes measures how long it takes for a committed piece of code to actually make it into production. I like the pizza delivery analogy: it’s the time from when the order is placed (a developer commits code) to when the pizza is hot and in the customer’s hands (the feature is live).

This metric is a fantastic diagnostic tool. It shines a light on the entire delivery workflow, from the moment a developer hits “commit” to the moment a user sees the result. Long lead times mean there’s friction somewhere in that process.

It’s important to note this metric is purely about execution speed. It doesn’t include the time spent in planning meetings or design sessions. The clock starts ticking the second a developer commits their code.

You can track this by pulling timestamps from your version control system (like Git) and your CI/CD tools. Getting this right is a huge part of figuring out team performance, and you can learn how to measure velocity in more detail to get the full picture. When you shrink this lead time, you directly boost your ability to react to customer feedback and stay ahead of the competition.

Gauging Your Stability: Change Failure Rate and Recovery Time

Speed is great, but it’s worthless without control. If you’re constantly swerving off the road, going fast doesn’t get you anywhere. That’s where the final two DORA metrics come in, shifting our attention from raw speed to the stability that actually builds customer trust.

These metrics are all about what happens after you ship. They’re the reality check that ensures your fast-moving team isn’t just shipping fast problems.

Change Failure Rate: Your Quality Report Card

How often does a new deployment break something? That’s the brutally honest question Change Failure Rate (CFR) answers. It’s a direct measure of your code quality and the rigor of your development process.

Think of it as the percentage of your deployments that immediately require a fix—like a hotfix, a rollback, or an emergency patch. A low CFR is a clear sign that your automated testing, code reviews, and pre-deployment checks are actually working.

The formula is simple:

CFR = (Number of Failed Deployments ÷ Total Number of Deployments) x 100

Elite teams keep their CFR between 0-15%. If yours is higher, it’s a big red flag. It usually points to underlying issues like brittle code, gaps in test coverage, or manual deployment steps that are prone to human error. Tracking this metric helps you stop guessing and start fixing the real weak spots in your pipeline.

Time to Restore Service: How Fast Can You Fix Things?

Okay, so something broke. It happens to the best of us. The next critical question is: how quickly can you fix it? That’s what Time to Restore Service (MTTR) is all about. This isn’t about placing blame; it’s about measuring your team’s resilience under fire.

When an incident occurs, the clock starts. It doesn’t stop until service is fully restored for your users. A low MTTR proves you have solid monitoring, a well-rehearsed incident response plan, and the skills to diagnose and deploy a fix—fast.

So, where do you get this data?

• Incident Management Tools: The lifecycle of a ticket in a platform like PagerDuty or Opsgenie is a goldmine.
• Alerting Systems: How much time passes between the first alert firing and the “all clear” message?
• Version Control: You can measure the time between a failed deployment commit and the commit that contains the fix.

Ultimately, these two stability metrics are the brakes and suspension on your high-speed delivery engine. They ensure that as you accelerate, you’re also building a product that’s reliable, robust, and worthy of your users’ trust.

Why DORA Metrics Are Your Competitive Advantage

Getting to know the four DORA metrics is one thing, but the real magic happens when you see them for what they truly are: a strategic business advantage. They’re not just technical numbers on a dashboard. In a world where speed and stability define the winners, DORA metrics give you a clear, proven roadmap to outpace your competition.

These metrics turn vague goals like “we need to innovate faster” into concrete, measurable actions.

The highest-performing teams, as defined by DORA, don’t just push code more frequently. They build healthier engineering cultures, capture more market share, and drive higher profitability. This isn’t just a happy accident; it’s the direct result of creating a software delivery machine that is both incredibly fast and rock-solid reliable.

The AI Accelerator Effect

The explosion of AI-powered coding tools has raised the stakes even higher. Sure, AI can write code at a mind-boggling pace, but all that code is completely useless if your delivery pipeline is slow, manual, and brittle. Without an efficient and stable process, AI-generated code just creates a massive bottleneck.

Think of DORA metrics as the foundation you need to actually cash in on the promise of AI.

A high Deployment Frequency and low Lead Time for Changes mean you can get those AI-generated features into your customers’ hands in a flash. At the same time, a low Change Failure Rate and a quick Time to Restore Service ensure that this breakneck pace of innovation doesn’t sacrifice quality or destroy customer trust.

The 2025 DORA Report uncovered a critical link here, finding that organizations with both high AI adoption and elite DORA scores absolutely crush their peers. For example, teams that deploy multiple times a day are more than twice as likely to see huge productivity gains from AI. Their median lead time for changes is less than a day, while lower-performing teams take days or even weeks to ship the same value.

You can find more insights in The DORA Report 2025 – a Thoughtworks perspective.

Ultimately, when you invest in improving your DORA capabilities, you’re investing in the future of your entire organization. It’s how you build a company that can adapt, innovate, and win.

Actionable Steps to Improve Your DORA Metrics

Knowing your DORA metrics is one thing, but actually improving them is where the real work begins. This is how you turn those numbers from a passive report card into an active engine for change. The secret isn’t a massive, disruptive overhaul; it’s about making small, consistent improvements that add up over time.

Recent industry data really drives this home. One report found that over 50% of teams are deploying less than once a week. And when things break? A staggering 15% of them take more than a full week to recover. The same report pointed out that nearly half of all engineering teams are stuck dealing with fundamental bottlenecks, like clunky manual testing and tedious deployment processes. Without fixing these core issues, even the most promising new technologies won’t move the needle. You can get a closer look at the data in the full AI readiness report.

Boosting Your Speed Metrics

If you want to ship more often (Deployment Frequency) and get changes out the door faster (Lead Time for Changes), the name of the game is removing friction.

• Embrace Serious CI/CD: Automate everything you can, from running tests to pushing code live. Every manual step you remove is a win for speed and reliability.
• Shrink Your Pull Requests: Stop letting massive features sit in code review for days on end. Break work into smaller, bite-sized chunks that are quick and easy for teammates to review and approve.
• Try Trunk-Based Development: When everyone works off a single main branch, it forces more frequent integrations. This naturally leads to smaller, continuous updates and a faster deployment rhythm.

Improving Your Stability Metrics

To lower your Change Failure Rate and shorten your Time to Restore Service, you need to build resilience into your systems and treat every incident as a lesson.

True stability isn’t about never failing; it’s about building a system so resilient that failures have minimal impact and recovery is almost instantaneous.

• Invest in Automated Testing: Your test suites are your first and best line of defense. When tests are thorough, they catch bugs early and give developers the confidence they need to deploy more frequently.
• Use Feature Flags: This is a game-changer. Feature flags let you separate deploying code from releasing a feature. You can push changes to production behind a flag, turn it on for a small group of users, and instantly turn it off if something goes wrong. It’s a huge safety net.
• Run Blameless Post-mortems: When an incident happens, the goal isn’t to find someone to blame—it’s to find out what in the process or system failed. This builds a culture of trust where people feel safe to talk about mistakes, turning every failure into a genuine opportunity to get better.

By focusing on these practical steps, you can start to chip away at the problems and improve the health of your entire software delivery process. If you want to get more granular on measurement, check out our guide on how to set the right KPI for engineering teams.

Got Questions About DORA Metrics?

As teams start digging into DORA, a few questions always seem to pop up. Let’s tackle some of the most common ones to help you clear any hurdles and really get the most out of them. It’s one thing to know what the metrics are, but it’s another thing entirely to know how to use them to make a real difference.

Are DORA Metrics the Only Thing We Should Measure?

Nope. Think of them as the vital signs for your software delivery process—they’re incredibly important, but they don’t tell the whole story. For a complete picture of performance, you need to look at them alongside other key signals.

Great teams often pair their DORA metrics with:

• Product Metrics: Are people actually using and loving what you’re building? Think user satisfaction and feature adoption rates.
• Business Metrics: Is your work moving the needle for the company? This could be anything from revenue growth to customer retention.
• Operational Metrics: Is the system stable and reliable? Keep an eye on things like overall system uptime and performance.

How Often Should We Track Our DORA Metrics?

Ideally, you want to track them continuously. Set up automated tools so the data is always there when you need it.

But the real magic happens when you review them consistently. Get in the habit of discussing them during your regular team retrospectives, maybe every week or two. This turns the metrics from a boring report card into a live dashboard that helps you navigate, spot trends, celebrate wins, and fix problems before they get out of hand.

Can a Small Team or Startup Benefit From DORA Metrics?

Absolutely. In fact, they can be a game-changer for smaller teams.

DORA gives you a simple, battle-tested framework to build good engineering habits from the very beginning. Instead of drowning in a sea of possible metrics, you can focus on the four that are directly linked to delivering value quickly and reliably. It helps you build a culture of continuous improvement right from the start, setting you up to scale without the growing pains.

A Practical Scorecard for Your DevOps Team

Knowing what the DORA metrics are is one thing. Actually using them to get better is a whole different ballgame. These four metrics give you a common, data-driven language to talk about—and improve—how you deliver software. By keeping an eye on Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Time to Restore Service, your team can finally stop relying on gut feelings and start building a truly high-performing engineering culture.

Think of this section not as a rigid report card, but as a practical guide to get you started. It breaks down the core ideas into simple cheat codes, thought-provoking questions, and a quick checklist to kickstart your journey. The real goal isn’t to hit a “perfect” score. It’s about building the habits of speed and stability into your team’s DNA. When you do that, your delivery pipeline stops being a bottleneck and becomes the engine that drives your business forward.

## Master Your DORA Metrics
Use this scorecard to transform your delivery pipeline from a bottleneck into a business driver.

### 📊 Core DORA Metrics
1. Deployment Frequency — How often you ship to production
2. Lead Time for Changes — Time from commit to production
3. Change Failure Rate — Percentage of deployments causing failure

### 🕹️ My Cheatcodes
- 🌱 Automate First — Remove manual steps from CI/CD to boost speed
- 🦎 Ship Small — Break work into small PRs for faster reviews
- ⚡ Go Blameless — Treat incidents as system failures, not human errors

### 📈 Reflection Points
- 💡 Where is the biggest bottleneck in our commit-to-deploy process?
- 🧩 Are we balancing our need for speed with the reality of stability?
- 📘 Do our post-mortems lead to real, actionable process improvements?