Engineering Delivery

What is DORA?

DORA is a long-running research programme that studies what makes software teams good at delivering software. Its best-known result is a set of five simple measures, the DORA metrics, that tell a team how quickly and how safely its changes reach the people who use them. This guide explains DORA from scratch, with no prior knowledge needed.

What does DORA stand for?

DORA stands for DevOps Research and Assessment. It is a research group that has studied software delivery for more than a decade, and it is now part of Google Cloud.

Every year DORA surveys thousands of people who build and run software, from developers to managers, in every kind of industry. The 2025 report, for example, drew on survey answers from nearly 5,000 technology professionals and more than 100 hours of interviews. Over the years, tens of thousands of people have taken part.

From those answers DORA looks for patterns: which ways of working go together with teams that ship often, rarely break things and stay healthy. It publishes what it finds in a yearly report (long called the Accelerate State of DevOps Report, and in 2025 the State of AI-assisted Software Development report) and on its website, dora.dev. The early research is also the basis of the book Accelerate (2018) by Nicole Forsgren, Jez Humble and Gene Kim.

Note: DORA in software delivery has nothing to do with the EU's Digital Operational Resilience Act, also shortened to DORA. That is a regulation about how banks, insurers and other financial firms manage technology risk. If you came here looking for the regulation, this is not it.

What problem does DORA solve?

DORA gives teams a fair, simple way to see how well they deliver software, without counting things that are easy to count but say little.

Before DORA, many organisations judged engineering by numbers such as lines of code written, hours worked or tickets closed. Those numbers are easy to inflate and say nothing about whether customers got anything useful. Worse, they can reward the wrong behaviour: a team that writes more code is not a team that delivers more value.

DORA asks a different question: once someone on the team has made a change, how fast and how safely does it reach the people who use the software? That question cares about outcomes, not activity. It also works for any kind of software, whatever language, tools or size of team.

The core idea: speed and stability go together

The most important finding from DORA's research is that going fast and staying stable are not a trade-off. The best teams do both.

It is easy to assume that shipping changes more often must mean breaking things more often. DORA's data says the opposite. Teams that ship small changes often tend to have fewer failures, because each change is small enough to test properly, easy to understand and quick to undo. In the 2025 report DORA calls the "speed versus stability" trade-off a myth: the two groups of teams that did best on both together made up nearly 40% of everyone surveyed (2025 report, page 19).

What are the five DORA metrics?

The DORA metrics are five measures of software delivery. Each one answers a simple question.

MetricThe question it answersGuide
Change lead timeOnce a change is made, how long until customers have it?Change lead time
Deployment frequencyHow often do we release changes to customers?Deployment frequency
Failed deployment recovery timeWhen a release goes wrong, how quickly do we fix it?Failed deployment recovery time
Change fail rateHow many of our releases need fixing straight away?Change fail rate
Deployment rework rateHow many of our releases were unplanned, made only to deal with a problem in production?Deployment rework rate

A few words in that table need explaining:

  • A change is any edit to the software: a new feature, a bug fix, a configuration tweak.
  • A deployment (or release) is the moment a change is put live, so real users get it.
  • Production is the live system your users use, as opposed to a test copy.

The five DORA metrics guide goes through each one in detail, with examples.

Throughput and instability: the two groups

DORA splits the five metrics into two groups, so you can see speed and stability side by side.

  • Throughput is how quickly changes flow to users. It covers change lead time, deployment frequency and failed deployment recovery time.
  • Instability is how often releases cause trouble. It covers change fail rate and deployment rework rate.

You want throughput to be high and instability to be low. Looking at only one group gives a lopsided picture: a team can look fast while breaking things, or look careful while making customers wait weeks for every fix.

A worked example

Here is how the metrics look for an imaginary team, so the numbers feel concrete.

A team of six builds an online booking app. Over the last month:

  • They released to customers 12 times, about three times a week. That is their deployment frequency.
  • A typical change took 3 days from being saved in their code history to reaching customers. That is their change lead time.
  • 2 of the 12 releases broke something and had to be undone straight away. That gives a change fail rate of 2 in 12, about 17%.
  • Each time, it took about 2 hours to put things right. That is their failed deployment recovery time.
  • 1 of the 12 releases was not planned at all: it went out only to deal with a problem customers reported in production. That gives a deployment rework rate of 1 in 12, about 8%.

None of these numbers is good or bad on its own. What matters is how they move over time for this team, and which one is holding them back. A lead time of 3 days, for example, might turn out to be mostly changes waiting for someone to review them.

What drives the metrics: capabilities and outcomes

DORA does not stop at the metrics. Its research model links three things in a chain: capabilities lead to better delivery, and better delivery leads to better results for the organisation and its people.

  1. Capabilities are the practices and conditions a team works with, such as automated testing, working in small batches, continuous integration, good documentation and a healthy team culture. DORA publishes a catalogue of them at dora.dev/capabilities.
  2. Software delivery performance is what the five metrics measure.
  3. Outcomes are what the organisation cares about in the end: how well the organisation performs, and the well-being of the people doing the work.

This matters because the metrics only tell you what is happening, not why. To improve them, you improve the capabilities underneath. A low deployment frequency could come from slow manual testing, a heavy approval process or worn-out teams, and each needs a different fix. The improving software delivery guide shows how to find the one to work on first.

How should a team use DORA?

Use DORA to help a team see where it stands and improve, never to judge or rank people.

DORA's own guidance, and the way its research is designed, points to a few habits:

  • Measure one application or service at a time. Different systems have different needs. A payments service and an internal reporting tool should not be held to the same numbers.
  • Compare with your own past. The most useful question is "are we getting better?", not "are we as good as someone else?".
  • Improve rather than chase a level. DORA's reports group teams into performance levels, but say plainly that improving matters more than reaching a level. See DORA performance levels.
  • Look at the metrics together. Pushing one number up while another quietly gets worse is not progress.
  • Keep it at team level. The metrics describe how a system of people, code and tools behaves. They are not a score for any one person.

Common misconceptions

A few ideas about DORA come up often and are worth clearing up early.

  • "DORA is a target to hit." It is not. When a number becomes a target, people find ways to move the number without improving anything. DORA warns against exactly this.
  • "Faster means riskier." The research shows the opposite tends to be true for teams that ship small changes often.
  • "We should compare our teams with each other." Teams build different things under different constraints. Comparing them invites gaming and blame, and DORA advises against it.
  • "DORA only works for big tech companies." DORA has found high-performing teams in every industry it has looked at (2024 report, page 15).
  • "Better tools alone will fix the numbers." Tools help, but the metrics move when practices and conditions change. This is also true of AI: DORA describes AI as an amplifier of what a team already does well or badly. See AI and software delivery.

How Solidafy uses this

Solidafy's Engineering Delivery app measures the DORA metrics from the tools your teams already use, and helps you read them the way DORA intends.

  • It reads deployments, changes and incidents from your code host, deployment pipeline and incident tool, and shows deployment frequency, change lead time, failed deployment recovery time, change fail rate and deployment rework rate.
  • Every figure is read against your own recent past, never an outside grade. Change fail rate is also shown per service, so one risky service does not hide inside a team average.
  • No one is ever ranked. The measures work at team and service level only. People are named only where an admin turns it on: on the lists a figure opens, with Names on items, and in the Claude Code place's By person view.
  • Changes opened by bots, such as Dependabot, are left out of the change measures.
  • Nothing is estimated. If a metric needs a data source you have not connected, the app says so instead of guessing.
  • Next to each metric there is a short guide on why it matters and how it is measured, which links to these pages.

The app can suggest goals from your own baseline, 10% better than now. DORA's 2025 report publishes no benchmark or target, so the app suggests none from it. Suggestions are yours to accept or edit, never a grade of your team. See How Solidafy uses this on the performance levels page.

The What is Engineering Delivery? guide explains the app itself: what each page shows and where each number comes from.

Where to go next

Learn more