DORA Metrics Explained: How to Measure Software Delivery Performance

“Are we getting faster?” is one of the hardest questions an engineering leader can answer honestly. Story points vary by team, lines of code reward the wrong behavior, and “it feels faster” will not survive a budget meeting.

DORA metrics give you a better answer. They come from more than a decade of research by Google’s DevOps Research and Assessment (DORA) program, and they measure the thing that actually matters: how quickly and safely changes reach your users. Better still, you can calculate them from tools you already use, such as GitHub, GitLab, Jira and your CI/CD system.

This guide covers each metric as DORA defines it today, how to collect the data, and how to avoid turning a useful signal into a vanity number.

What DORA metrics are

DORA started as an independent research program and is now part of Google Cloud. Each year it surveys thousands of technology professionals and publishes a report on what separates high-performing software teams from the rest. By its tenth report in 2024, DORA said it had heard from more than 39,000 professionals, and the 2025 report, focused on AI-assisted software development, surveyed nearly 5,000 more.

From that research came a small set of delivery metrics that work regardless of language, cloud or team size. Many people still call them “the four keys,” but the model has changed:

• 2014–2015: Early DORA studies measured deployment frequency, lead time and mean time to recover, then grouped them with change fail rate into throughput and stability.
• 2023: Mean time to recover was renamed failed deployment recovery time and narrowed to failures caused by a change to production.
• 2024: Deployment rework rate was added as a fifth metric, and the set was regrouped into throughput and instability.

The 5 DORA metrics at a glance

DORA’s key finding is that speed and stability are not a trade-off. Teams that ship more often in small batches tend to have lower failure rates, not higher ones.

The throughput metrics

Change lead time

This is the time from a commit landing in version control to that change running in production. It tells you how long finished work waits in review queues, test stages, release trains and approval gates.

How to collect it: For each production deployment, find the commits it included and subtract each commit time from the deployment finish time. Most teams report the median per week or month. Some tools, such as GitLab’s built-in DORA analytics, start the clock at merge request merge rather than first commit, so check which definition your tool uses and stick with it.

Deployment frequency

How often you deploy to production. A team deploying several times a day and a team deploying once a quarter are working in very different ways, with very different batch sizes.

How to collect it: Count successful production deployments from your pipeline, for example GitHub Actions or GitLab environment deployments, Azure Pipelines release runs, or your deployment tool’s audit log. If your deploys are manual, add a single step that records each release.

Failed deployment recovery time

When a deployment breaks something and needs immediate intervention, how long until users are back to normal? This replaced the older mean time to recover because DORA wanted to measure recovery from failures caused by changes, not every outage, such as a cloud provider incident.

How to collect it: Link incidents to the deployment that caused them, then measure from deployment (or detection) to resolution. Incident tools and status page timestamps help, but the link to a specific deploy is what matters.

The instability metrics

Change fail rate

The share of deployments that need immediate intervention, such as a rollback, a hotfix or a feature flag kill switch. If 4 out of 50 deployments needed fixing, your change fail rate is 8%.

How to collect it: Tag rollbacks and hotfixes in your pipeline, or label incidents with the deployment ID that caused them. Divide failed deployments by total deployments for the period.

Deployment rework rate

The share of deployments that were not planned and happened only because of a production incident. It captures the hidden cost of instability: every emergency deploy is time not spent on planned work.

How to collect it: Mark deployments as “planned” or “incident-driven,” for example with a branch naming convention such as hotfix/ or a required label on the pull request. Divide incident-driven deployments by all deployments.

Key takeaway: You do not need a dashboard product to start. Three data sources cover all 5 metrics: your Git history, your deployment log and your incident tracker. The hard part is linking them consistently, not collecting them.

Collecting DORA metrics from tools you already use

Here is a practical map of common tools and what each one gives you.

Google once published an open-source project called Four Keys to pull these metrics from GitHub or GitLab into a dashboard, but the repository was archived in January 2024 and is now read-only. It remains useful as a reference design, not as a maintained tool.

DORA’s own advice is to start with conversations rather than integrations. Map how a change moves from idea to production, then automate data collection once everyone agrees on the definitions.

Common mistakes that ruin the numbers

DORA’s guidance is explicit on several points, and they match what goes wrong in practice:

• Turning metrics into targets. When deployment frequency becomes a bonus target, people split deploys into meaningless pieces. Use metrics to find bottlenecks, not to rank people.
• Comparing teams against each other. A mobile app with app store review and a backend API will never look the same. DORA recommends measuring one application or service at a time.
• Blending everything into one company number. An average across 40 services hides the 3 that are struggling.
• Watching one metric alone. Speed without stability, or stability without speed, tells half the story. Review all 5 together.
• Ignoring definitions. If one team counts staging deploys and another does not, the comparison is meaningless.

How to use DORA metrics to improve

Metrics are only worth collecting if they change decisions. A simple cycle works for most teams:

1. Baseline. DORA’s Quick Check asks 5 multiple-choice questions, takes under a minute and compares your answers with industry data. It is a fast way to see where you stand before you automate anything.
2. Find the constraint. Long lead time often points to slow code review, flaky tests or manual approval gates. A high change fail rate often points to weak automated testing.
3. Make batches smaller. DORA’s research consistently finds that smaller changes improve both throughput and stability. Trunk-based development, feature flags and a solid CI/CD pipeline all help.
4. Recheck in a month. Look at trends, not single data points.
5. Discuss in retrospectives. Share ownership of the numbers across development, operations and release teams.

AI coding tools make this more important, not less. DORA’s 2025 report found AI adoption now correlates with higher delivery throughput but still correlates with lower delivery stability, describing AI as an amplifier of a team’s existing strengths and weaknesses. If AI coding assistants increase change volume without stronger testing, your instability metrics will show it first.

Where to start this week

1. Pick one service that matters to customers and has an active team.
2. Write down definitions: what counts as a production deployment, what counts as a failure needing immediate intervention, and when an incident is resolved.
3. Pull 90 days of data from your Git host, pipeline and incident tool into a spreadsheet.
4. Calculate the 5 metrics by month: median lead time, deployment count, change fail rate, rework rate and median recovery time.
5. Share the results with the team and ask one question: what is slowing us down the most?
6. Automate later. Once definitions are stable, move the calculation into your data warehouse, a built-in analytics feature or a dedicated tool.

DORA metrics pair well with reliability targets. Delivery metrics show how well you ship change, while SLOs show whether users get the reliability they need. Our comparison of DevOps vs SRE explains how those two views fit together, and SLA vs SLO vs SLI covers the reliability side. New to the vocabulary? Try the glossary.

The bottom line

DORA metrics give engineering teams a shared, evidence-based language for delivery performance. Learn the 5 current definitions, collect them per service from tools you already use, and treat them as a guide for improvement rather than a scoreboard. The teams that get the most from DORA are the ones that ask “what is our biggest bottleneck?” every month and then fix it.

Sources

• DORA: Software delivery performance metrics — current definitions of the 5 metrics and collection guidance
• DORA: A history of DORA’s software delivery metrics — 2023 rename of recovery time and 2024 addition of rework rate
• DORA Quick Check — 5-question benchmark tool
• GitLab Docs: DORA metrics — how a built-in tool calculates the metrics and tier requirements
• Google Cloud Blog: Announcing the 2025 DORA Report — AI findings and survey size
• Four Keys repository on GitHub — archived open-source DORA dashboard project