DORA Metrics: What They Are and How to Measure Them
Edvaldo Freitas
With AI in development, generating code has become easier. The problem is that more code does not automatically mean better delivery. The team may open more PRs, overload review, run more pipelines, and still take longer to get good changes into production. This is where DORA Metrics help: they show how the delivery flow is actually working.
The most common mistake is using DORA as if it were a productivity dashboard. But DORA helps more when it answers other questions: where work is getting stuck, where quality is failing, and how long the team takes to recover when something breaks.
DORA Metrics came from the DevOps Research and Assessment research, now part of Google Cloud. They became known for the four classic metrics: Lead Time for Changes, Deployment Frequency, Change Failure Rate, and MTTR. More recently, DORA itself started describing a model with five metrics, including Deployment Rework Rate and using Failed Deployment Recovery Time for a more precise reading of recovery after failed deployments.
In practice, when someone talks about “DORA Metrics,” they are usually talking about the four classic metrics. They are a good starting point, as long as they are not read in isolation. The same number can mean very different things depending on the service, the team, and the type of product being delivered.
What are DORA Metrics?
DORA Metrics are metrics used to measure the performance of the software delivery flow. They help engineering teams understand whether they can deliver changes frequently, with little delay, with a low failure rate, and with good recovery capacity.
They help more than activity metrics, such as number of commits, lines of code, or open pull requests. Those numbers show that something is happening, but they do not show whether delivery has improved. A team can look busy and still deliver little value, make fragile deployments, or accumulate risk along the way.
A team can make many small commits and still take weeks to get changes into production. It can also open many PRs and create a review queue that blocks everyone. DORA forces the conversation to move away from work volume and toward the outcome of the delivery system.
What are the four DORA metrics?
The four most used DORA metrics measure two sides of the same flow: speed and stability. Speed appears in Deployment Frequency and Lead Time for Changes. Stability appears in Change Failure Rate and MTTR, or, in the more recent model, Failed Deployment Recovery Time.
| Metric | What it measures | Why it matters | Where to investigate when it gets worse |
|---|---|---|---|
| Deployment Frequency | How often the team deploys to production in a given period | Shows whether the team can deliver in small, frequent batches | Pipeline, approvals, fear of deployment, large PRs, dependencies between teams |
| Lead Time for Changes | Time between the commit of a change and the deployment to production | Shows how long a change takes to reach the user | Time before opening a PR, time in review, slow CI, manual QA, waiting for deployment |
| Change Failure Rate | Percentage of deployments that cause an incident, rollback, hotfix, or intervention | Shows whether frequent delivery is maintaining enough quality | Fragile tests, superficial review, large PRs, low observability |
| MTTR or Failed Deployment Recovery Time | Average time to recover the service after a failure | Shows the team’s ability to respond when production breaks | Alerts, rollback, playbooks, ownership, diagnosis, and logs |
Deployment Frequency: how to measure deployment frequency
Deployment Frequency measures how often a team puts changes into production during a period. It can be per day, week, month, or sprint, as long as the criterion is consistent.
The simple way to calculate it is:
Deployment Frequency = number of production deployments / analyzed period
If a service had 20 deployments in 10 business days, the average frequency was 2 deployments per business day. In a team with continuous deployment, it may make more sense to look at the daily or weekly median, because the average can hide days with no deployments and days with several concentrated deployments.
How to interpret this DORA Metric
Frequent deployment usually indicates that the team can work on smaller changes, review with less friction, and put code into production without accumulating as much risk. When deployment happens rarely, the problem is usually in the flow: PRs that are too large, too many manual approvals, an unstable pipeline, or fear of breaking production.
This reading needs to be done per service. An internal backend with controlled deployment does not have the same rhythm as a SaaS with continuous release. The problem is not simply deploying too little. The problem is having changes ready and still waiting days or weeks to put them into production.
When deployment frequency drops, a few questions help find the bottleneck:
- Do already approved changes sit idle after merge?
- Does the team depend on a fixed release window?
- Does the pipeline fail often for reasons unrelated to the change?
- Is there a lot of dependency between teams to release a small change?
- Do PRs become too large to review safely?
Lead Time for Changes: how to measure time to production
Lead Time for Changes measures the time between the first commit of a change and the moment it reaches production. This is one of the most useful metrics for technical leadership, because it shows the real time a change takes to move through the system.
The basic formula is:
Lead Time for Changes = production deployment timestamp – first commit timestamp
Example:
- First commit: January 1, at 10 a.m.
- Production deployment: January 5, at 4 p.m.
- Lead Time: 4 days and 6 hours
This calculation looks simple, but the definition needs to be agreed on first. Some teams measure from the first commit. Others measure from the opening of the pull request. To compare over time, choose one definition and keep the same logic.
DORA Metrics become more useful when you break down lead time
The aggregate number shows that there is a delay, but it does not show where it happens. To find the bottleneck, break lead time into smaller steps:
- Time between first commit and PR opening
- Time until the first review
- Time between first review and approval
- Time between approval and merge
- Time between merge and deploy
This breakdown changes the conversation. If the longest time is before the PR is opened, maybe the tasks are too large. If the delay is in review, there may be lack of context, too few available reviewers, or PRs that are hard to review. If the code sits idle after merge, the bottleneck may be in the pipeline or release process.
For teams using AI to generate code, this metric deserves even more attention. AI can reduce writing time, but increase review time if the code arrives larger, with less context, or with changes spread across too many files. In that case, lead time does not improve because the bottleneck moved from writing to review.
Change Failure Rate: how to calculate the failure rate of changes
Change Failure Rate measures the proportion of deployments that cause some problem in production. It can be a rollback, hotfix, incident, relevant degradation, or any change that requires immediate intervention.
The formula is:
Change Failure Rate = failed deployments / total deployments x 100
Example:
- Deployments in the month: 40
- Deployments that required rollback or hotfix: 4
- Change Failure Rate: 10%
The hard part is not the calculation. It is defining what counts as a failure. Does a small bug fixed later enter the metric? Does a false alert enter? Does a preventive hotfix enter? The team needs to agree on the rule, otherwise each person will classify it differently.
What this metric reveals about code review
When the failure rate increases, there is usually some problem before production. It may be insufficient automated testing, a misunderstood requirement, a change that is too large, or review done only to approve syntax.
Code review matters here because many failures do not appear as an obvious error in the diff. The code may compile, the tests may pass, and still the change may break a business rule, create a heavy query, unintentionally change a permission, or touch a flow the author did not know well.
With coding assistants, this care becomes even more important. Generated code may look correct in a quick read, but it still needs to be reviewed within the product context. Good review is not just looking for bugs. It is asking whether that change makes sense for that service, in that flow, and with that risk.
MTTR and Failed Deployment Recovery Time: how to measure recovery
MTTR, or Mean Time to Recovery, measures how long the team takes to restore the service after a failure. In many teams, it is calculated by the average duration of incidents.
The formula is:
MTTR = total incident duration / number of incidents
Example:
- Incidents in the month: 3
- Total duration: 135 minutes
- MTTR: 45 minutes
DORA also started using the term Failed Deployment Recovery Time, which focuses on recovery time after a failed deployment that required intervention. This change helps separate incidents caused by deployment from other types of operational failure.
For many teams, this distinction is useful. If the service went down because of an external infrastructure problem, that says one thing. If it went down because a deployment broke checkout, that says another. Both situations can enter an operational analysis, but they require different actions.
What to look at when recovery takes too long
A high recovery time usually appears when the team takes too long to detect, diagnose, or revert. Each step has a different cause.
- When detection takes too long, the team may not have reliable alerts or may be dealing with too much noise.
- If diagnosis takes too long, logs, traces, and ownership are probably poor.
- If reverting takes too long, rollback may depend on a manual action or on a specific person.
- If the same incident comes back, the postmortem is not generating real changes in the system.
MTTR does not improve just by pressuring the team to “solve things faster.” Recovery becomes more efficient when the system helps: smaller deployments, feature flags, simple rollback, good observability, and autonomy to act when something breaks in production.
DORA Metrics benchmarks
Benchmarks help provide a reference, but they should not become a ranking between teams. A legacy service with regulated deployment, a new app, and an internal API operate under different constraints. That is why the most useful comparison is usually the team against itself, looking at evolution over time.
Since DORA classifications have changed over the years, use the ranges below as a reference, not as a fixed rule.
| Metric | Attention range | Healthy range for many teams | How to interpret |
|---|---|---|---|
| Deployment Frequency | Less than 1 deployment per month | Weekly, daily, or several times per day, depending on the service | May indicate large PRs, an unstable pipeline, or too much manual approval. |
| Lead Time for Changes | More than 1 month | Less than 1 week, or less than 1 day in teams with a more mature flow | When it goes up, break it down by step to find out whether the delay is in the PR, review, CI, or deploy |
| Change Failure Rate | Above 15% requires investigation | Between 0% and 15%, while being careful not to mask failures | With few deployments, it may hide a process that is too conservative or failures that are not being recorded. |
| MTTR or Failed Deployment Recovery Time | More than 1 day | Less than 1 hour in services with good operations | Depends on the quality of alerts, ease of rollback, diagnosis, and the autonomy of the team responsible for the service. |
A benchmark alone does not say much. The same lead time of three days may be good for a complex service and bad for a simple API with small changes. Context is what turns the number into a diagnosis.
How to create a simple pipeline to measure DORA
Before buying a tool or building a large dashboard, the first step is to define how each metric will be measured. The worst way to implement DORA is to let each team measure in its own way and then treat the numbers as if they were comparable.
Start with a simple definitions table:
| Metric | Initial event | Final event | Data source |
|---|---|---|---|
| Lead Time for Changes | First commit or PR opening | Deployment to production | Git, GitHub, GitLab, CI/CD tool |
| Deployment Frequency | Deployment started | Deployment completed in production | GitHub Actions, Jenkins, CircleCI, ArgoCD, release tool |
| Change Failure Rate | Deployment to production | Incident, rollback, hotfix, or intervention linked to the deployment | CI/CD, incident management, observability, issue tracker |
| MTTR | Incident detected | Service restored | PagerDuty, Opsgenie, Datadog, New Relic, postmortems |
After that, automate collection gradually. It does not need to start perfect. Often, an initial dashboard with approximate data already reveals where the flow is getting stuck.
A simple way to start:
- Choose one service or product to measure first.
- Define the events that count for each metric.
- Extract data from the tools the team already uses.
- Manually validate a sample of the numbers.
- Review the data with the team every sprint or month.
- Choose one small improvement based on the bottleneck found.
The main care point is not turning the dashboard into the final goal. If a metric does not help the team make decisions, it becomes just another number on the screen. When the team looks at lead time and still does not know what to investigate, the metric is probably too aggregated.
How to use DORA without falling into micromanagement
DORA measures the delivery system, not individual productivity. Using these metrics to pressure devs by number of deployments or time between commits creates bad incentives and makes the data less reliable.
A simple example: when the team starts chasing Deployment Frequency at any cost, it may start making small deployments that do not deliver anything relevant. When the pressure is to reduce Lead Time, it may push changes with less review. And when the focus becomes lowering Change Failure Rate above everything else, the team may reduce deployment frequency and become too conservative.
The best use is to turn each number into a question:
- Lead time went up in recent weeks. In which step did it go up?
- Deployment frequency dropped. Is there a ready change sitting idle?
- Failure rate increased. Do the failures have something in common?
- Recovery time got worse. Was it a delay to detect, diagnose, or revert?
This difference changes the team’s behavior. The metric stops being a pressure mechanism and becomes a way to choose where to adjust the process.
How AI, pull requests, and code review affect DORA Metrics
Coding assistants can speed up writing, but they do not solve the entire delivery flow. After the code is generated, it still needs to go through review, tests, integration, and deploy. This is where DORA Metrics help show whether the extra speed became real delivery or just moved the bottleneck to another step.
In teams without a healthy review flow, AI can increase the volume of PRs faster than the team can review them. This appears in lead time: PRs sit idle, reviewers need to deal with more context, and small changes start competing for attention with large changes.
The effect also appears in Change Failure Rate. When review becomes a superficial check, more problems reach production. Not because “AI writes bad code” by default, but because more changes enter the flow without proportional validation.
To understand the reason behind the numbers, also look at:
- Time until the first comment on the PR
- Total time in review
- Average PR size
- Number of files changed per PR
- Rate of reopened or reverted PRs
- Types of problems found in review
This is where AI-assisted code review can help, as long as it is used with criteria. As long as it enters as support for the flow. The value is not in approving any change faster, but in reducing waiting time, bringing context, pointing out recurring risks, and letting the reviewer focus on decisions that require judgment.
If the team uses a tool like Kodus, for example, the team can track signals that explain the behavior of DORA Metrics: whether first feedback arrives faster, whether repeated problems appear less often in production, and whether large PRs receive alerts before they become a bottleneck. These signals do not replace DORA, but they help understand why the numbers improve or get worse.
Common mistakes when implementing DORA Metrics
Measuring without a baseline
Without a starting point, any change looks like an opinion. Measure for a few weeks before changing the process. Even if the data is not perfect, it helps the team compare trends.
Comparing different teams as if they were the same
A team maintaining a regulated legacy system should not be compared directly with a team working on a new, isolated service. DORA works better by application or service, with clear context.
Optimizing one metric in isolation
Increasing deployments without looking at failures can make production worse. Reducing lead time without looking at review can push risk forward. The metrics were designed to be read together.
Using metrics to pressure people
When the metric becomes individual pressure, the team starts optimizing the number, not the system. Then distortions appear: artificial deployments, misclassified incidents, PRs broken into unnecessary pieces, and hidden work outside the measured flow.
Building a big dashboard before knowing the question
Dashboards with many metrics often create a false sense of control. Start with a simple question, such as “why did our lead time go up?” or “why are deployments failing more?”. Then look for the data needed to answer it.
Other metrics that complement DORA
DORA shows the outcome of the delivery flow, but it does not always explain the cause. That is why some teams combine DORA with flow metrics, code review, and developer experience.
Some useful metrics:
- Cycle time: time between the active start of work and delivery.
- Review time: time a PR spends waiting for or receiving review.
- PR size: average size of pull requests, in files, lines, or functional scope.
- Queue time: time sitting idle between steps, such as waiting for review, QA, or deployment.
- Rework: how much work comes back because of a bug, misunderstood requirement, or incomplete change.
- Developer experience: signs of friction in the environment, CI, local setup, and internal tools.
These metrics should explain DORA, not compete with it. If lead time is high, review time and queue time help find where the flow got stuck. If the failure rate went up, rework and types of review comments help understand what is slipping through.
How to start without making the process heavy
A simple way to start is to choose one service and one question. For example: “why are small changes taking so long to reach production?”. From there, measure Lead Time for Changes and break the time down into steps.
After two or three weeks, look at the data with the team. If the biggest delay is in review, work on PR size, reviewer distribution, and the type of feedback that arrives too late. If the delay is after merge, look at CI, deploy, and approvals.
For Change Failure Rate, start by recording deployments that required rollback, hotfix, or incident. You do not need to solve the entire failure taxonomy at the beginning. The important thing is to create a rule the team can apply consistently.
For MTTR, choose a simple definition of incident start and end. Then separate detection, diagnosis, and recovery time. This separation avoids a generic discussion about “we took too long” and moves the team toward clearer actions.
FAQ about DORA Metrics
What are DORA Metrics?
DORA Metrics are software delivery metrics used to measure speed and stability. The four best-known ones are Deployment Frequency, Lead Time for Changes, Change Failure Rate, and MTTR. The current DORA model also considers Deployment Rework Rate and Failed Deployment Recovery Time.
What are the 4 DORA metrics?
The four classic DORA metrics are Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Recovery. They help understand deployment frequency, time to production, failure rate, and recovery capacity.
What is the difference between Lead Time and Cycle Time?
Lead Time for Changes usually measures from commit to deployment in production. Cycle Time can measure the time from the active start of work to delivery. The exact difference depends on the team’s definition, so it is important to document the events used in each calculation.
What is a good deployment frequency?
It depends on the context. For many teams, daily deployment or several deployments per day can be a healthy sign. In products with more restrictions, a weekly frequency can make sense. The warning sign appears when ready changes sit idle without a clear technical reason.
Is Change Failure Rate below 15% good?
In many benchmarks, below 15% appears as a healthy range. Even so, the number needs context. A very low rate with few deployments may indicate that the team avoids changes. It may also indicate that failures are not being recorded correctly.
Do DORA Metrics work for small teams?
Yes, but the reading needs to consider the size of the team. When there are few deployments or few incidents, the average can fluctuate a lot. That is why it is worth looking more at trends and flow bottlenecks than at a rigid comparison with benchmarks.
How does code review affect DORA Metrics?
Code review mainly affects Lead Time for Changes and Change Failure Rate. When review takes too long, the change takes longer to reach production. When review is superficial, problems can slip through and appear later as an incident, rollback, or hotfix.
Should I use DORA Metrics to evaluate developers?
No. DORA measures the delivery system. Using these metrics to evaluate people creates bad incentives and reduces trust in the data. They work better when the team uses the numbers to improve process, tooling, architecture, and delivery quality.
Wrapping up
DORA Metrics help when they become a conversation about the real delivery flow. They show whether the team is delivering frequently, how long a change takes to reach production, how many changes fail, and how long recovery takes.
These numbers help when they lead the team to investigate concrete causes: large PRs, slow review, unstable CI, weak tests, manual deployment, low observability, or difficult rollback. For teams using AI in development, this reading becomes even more necessary, because producing code faster does not guarantee better delivery.
Start small. Choose one service, agree on the definitions, validate the data, and tackle one bottleneck at a time. DORA Metrics does not need to become a huge dashboard. It needs to help the team understand where work gets stuck and what to change first.