What Are DORA Metrics? A Practical Guide for Engineering Teams

What Are DORA Metrics?

DORA metrics are four (now five) research-backed measurements — deployment frequency, change lead time, change failure rate, and failed deployment recovery time — that track how fast and how safely a software team ships code to production. They come from a decade of research across 39,000+ professionals and are the closest thing the industry has to a standard for measuring software delivery performance.

Your team ships fast. But is it shipping well? Deployment frequency alone doesn't answer that. Neither does change failure rate on its own. You need both speed and stability measured together to get the real picture — which is exactly what DORA was built to do.

This guide covers what each metric means, how to calculate them from your git data, the official benchmarks, what changes when AI writes a chunk of your codebase, common mistakes, and when DORA isn't enough on its own. For a concise reference, see our DORA metrics glossary entry.

Where DORA Came From

DORA stands for DevOps Research and Assessment. It was co-founded in 2015 by Dr. Nicole Forsgren, Jez Humble, and Gene Kim. Their research started in 2014 with the annual State of DevOps Report (originally published with Puppet), and by 2018 they'd published Accelerate: The Science of Lean Software and DevOps, summarizing four years of findings.

Google Cloud acquired DORA in December 2018. The research has continued every year since, and the 2024 report marks the 10th anniversary with data from over 39,000 professionals globally. The book won the Shingo Research and Professional Publication Award in 2019.

One of DORA's core findings: speed and stability are not tradeoffs. Top-performing teams score well on all metrics. Low performers score poorly across the board. You don't have to choose between moving fast and keeping things stable.

The Four DORA Metrics (Plus the Fifth)

DORA groups its metrics into two dimensions: throughput (how fast you deliver) and stability (how reliable those deliveries are).

Throughput Metrics

Stability Metrics

Official Performance Benchmarks

DORA uses cluster analysis across thousands of survey respondents each year to define performance tiers. These numbers shift annually (the 2022 report only detected 3 clusters, no Elite tier), but here are the widely referenced benchmarks:

The gap between Medium and Low is dramatic. Low-performing teams have a 64% change failure rate vs. 5% for Elite. Their recovery time stretches from hours to months. These aren't small differences.

How to Calculate DORA Metrics from Git Data

You can derive DORA metrics from your existing git and CI/CD data. Here's how each one maps to data you already have.

Deployment Frequency

Count the number of successful deployments to production in a given period. If you use CI/CD pipelines, count pipeline runs that deploy to production. A common git-based proxy: count merged PRs to your main branch that trigger a deployment pipeline.

deployments_this_month = count(successful_deploys_to_production)
frequency = deployments_this_month / days_in_month

Change Lead Time

Measure the time from the first commit on a branch (or PR creation) to when that code is deployed to production. You can pull this from the GitHub API using PR creation timestamps and deployment timestamps.

lead_time = deployment_timestamp - first_commit_timestamp
average_lead_time = sum(all_lead_times) / count(deployments)

Change Failure Rate

Divide the number of deployments that caused incidents by the total number of deployments. This requires tagging failed deployments in your CI/CD system or linking deployments to your incident tracking tool.

cfr = (failed_deployments / total_deployments) * 100

Recovery Time

Measure the elapsed time between a failed deployment and the next successful deployment on that service. You can also use incident creation to incident resolution timestamps from your incident management tool.

recovery_time = next_successful_deploy - failed_deploy_timestamp
average_recovery = sum(all_recovery_times) / count(failures)

Google's DORA team also maintains an open-source project called Four Keys that sets up a data ingestion pipeline from GitHub or GitLab through Google Cloud into a dashboard. It's a solid starting point if you want to build your own measurement system.

DORA Metrics in the AI Coding Era

DORA's four metrics were designed around a world where a human wrote every line and review capacity roughly matched code output. That assumption is under real pressure now that AI coding tools generate a significant share of committed code on many teams. The metrics still work — but reading them the old way can be misleading.

The core risk: deployment frequency can climb for the wrong reason. More code is shipping because more code is being generated, not because your delivery process got healthier. Meanwhile, review capacity doesn't scale at the same rate — engineers can merge AI-generated PRs faster than they can properly review them.

That mismatch shows up in one of two places: either lead time quietly grows because reviewers are drowning in a larger volume of PRs, or review gets rushed and change failure rate creeps up later, often with a lag that makes the cause hard to trace back to a specific change. A flat change failure rate can also hide a growing problem — if deploy volume doubles and the failure percentage stays the same, you're still shipping twice as many failures in absolute terms.

The practical fix: don't read deployment frequency in isolation in 2026. Track it alongside PR review time and time-to-first-review. If deployment frequency is climbing while review time is flat or shrinking, that's a real efficiency gain. If deployment frequency is climbing and review time is climbing too, reviews are becoming a bottleneck — or getting skipped, which is worse.

Why DORA Metrics Matter for Business Outcomes

DORA isn't just about engineering efficiency. The research found a direct link between software delivery performance and organizational performance.

• Top performers are 2x more likely to meet or exceed their organizational goals, including profitability, market share, productivity, and customer count (source: Accelerate, based on 2014-2017 data)
• Teams with superior documentation substantially outperformed peers in reliability and across all DORA metrics (2024 report)
• Psychological safety and team autonomy emerged as strong predictors of software delivery performance (2024 report)
• Organizations using balanced measurement strategies (DORA plus complementary metrics) reported 3-12% efficiency gains, 14% increases in R&D focus, and 15% improvements in developer engagement

10 Common Mistakes When Implementing DORA

1. Turning metrics into targets

Goodhart's Law: "When a measure becomes a target, it ceases to be a good measure." Saying "every team must deploy multiple times per day by Q4" incentivizes gaming, not improvement.

2. Gaming with trivial deployments

Pushing many small, inconsequential updates to inflate Deployment Frequency without delivering real value. The metric goes up but nothing improves.

3. Using one metric in isolation

Optimizing for deployment frequency while ignoring change failure rate means you're shipping bugs faster. The metrics are designed to work as a set.

4. Making unfair cross-team comparisons

Creating league tables that rank teams against each other ignores context. A web frontend team will naturally deploy more frequently than a mobile app team or a team working on embedded systems. Comparing them is misleading.

5. Rushing changes to improve Lead Time

Skipping code reviews or automated tests to get a lower lead time number produces buggy software. Speed at the expense of quality defeats the purpose.

6. Not measuring long enough before setting baselines

Teams need at least 2-3 months of data before deciding what "good" looks like for their specific context. A single sprint doesn't give you a reliable baseline.

7. Ignoring why metrics change

DORA shows what changed but not why. A spike in lead time might mean your pipeline is broken, or it might mean half the team was on holiday. External factors like absent code owners or company events skew results.

8. Applying DORA to teams with long release cycles

Teams that release monthly or quarterly will inherently show "low" deployment frequency. That doesn't mean they're performing poorly. The benchmarks assume continuous delivery pipelines.

9. Optimizing past diminishing returns

Going from 1 deployment per month to 1 per week is a big win. Going from 5 per day to 10 per day probably isn't. The framework doesn't tell you when to stop optimizing.

10. Not supplementing with other metrics

DORA measures pipeline performance but misses PR review time, first-response time on code reviews, work categorization (features vs. bugs vs. tech debt), and developer experience. You need additional signals to get the full picture.

What DORA Doesn't Measure (and Its Limitations)

DORA is useful but it has real blind spots. Knowing these prevents you from over-relying on four numbers to run your engineering org.

• Value delivered: DORA tracks how fast code moves through a pipeline but not whether that code solves real customer problems
• Invisible work: Mentoring, architecture decisions, technical debt reduction, and cross-team collaboration are not captured
• Platform and infrastructure: Security, scalability, and maintainability aren't directly measured
• Developer experience: How developers feel about their tools, processes, and work isn't part of DORA (that's where SPACE comes in)
• Survey-based benchmarks: DORA's data comes from self-reported surveys, which introduces response bias. Teams may over- or under-report their actual performance

SPACE Framework: Filling the Gaps DORA Leaves Open

The SPACE framework was created in 2021 by Nicole Forsgren (yes, the same person who co-founded DORA), Margaret-Anne Storey, and colleagues at Microsoft Research. It was published in ACM Queue and expands the measurement picture across five dimensions:

DORA's metrics primarily cover the Activity and Performance dimensions. SPACE adds satisfaction, collaboration, and flow. The recommended approach is to start with DORA for delivery baselines, then layer in SPACE for a fuller picture of engineering health.

One practical guideline from the framework: pick at least 3 of the 5 dimensions, balance quantitative and survey data, and only report aggregated team-level results. Never use SPACE (or DORA) to evaluate individual developers.

Tools That Measure DORA Metrics

Several tools can automate DORA measurement. They differ primarily in how they define a "deployment" and how they link incidents to deployments.

For a broader comparison of tools that track git activity and team metrics, see our guide to git reporting tools.

How to Get Started with DORA

You don't need to buy an expensive platform to start measuring DORA. Here's a practical path:

• Week 1-2: Pick one metric to start with. Deployment Frequency is the easiest because you can count merged PRs or CI/CD runs to production.
• Week 3-4: Add Change Lead Time. Use PR creation and merge timestamps from your git platform. Most git providers expose this through their API.
• Month 2: Add Change Failure Rate and Recovery Time. These require linking your deployments to your incident tracking (PagerDuty, Opsgenie, or even a spreadsheet).
• Month 3+: Establish baselines. Resist comparing to the DORA benchmarks immediately. Your context matters more than industry averages.

The goal isn't to reach "Elite" on every metric. It's to understand where your bottlenecks are and improve over time. A team that moves from Low to Medium performance has made a more meaningful improvement than an Elite team optimizing by 5%.

Frequently Asked Questions

Where Gitmore Fits In

Gitmore doesn't calculate DORA metrics directly. What it does is give you automated visibility into the daily git activity that feeds into those metrics: what got deployed, what PRs merged, what work categories the team focused on, and where things are stuck.

Think of it this way: DORA tells you your lead time is 5 days. Gitmore's daily reports tell you why it's 5 days, because you can see that PRs sit in review for 3 of those days. The metrics and the narrative work together.