DORA metrics

DORA Metrics for Software Delivery Performance

DORA metrics show how quickly a team ships software and how often releases create failures or rework across five measures of software delivery performance. Together, they give a team a useful view of delivery speed and stability.

Many developers still know DORA as the Four Keys: deployment frequency, lead time for changes, change failure rate, and time to restore service. DORA’s current model uses five metrics. The recovery metric now focuses on failed deployments, and deployment rework rate has been added as a fifth measure.

The practical takeaway is simple. Teams do not have to choose between shipping quickly and keeping production stable. Small changes that are easy to understand, review, test, and roll back tend to move faster and cause fewer late-night fixes.

What Are the Five DORA Metrics and How Are They Calculated?

DORA groups the five metrics into throughput and instability. Throughput tells you how smoothly work moves into production. Instability tells you how much trouble shows up after it gets there.

Change lead time, deployment frequency, and failed deployment recovery time are throughput metrics. Change fail rate and deployment rework rate measure instability. DORA’s history of software delivery metrics explains how the original Four Keys became the current five-metric model.

Measure these numbers for one application or service at a time. A web service that deploys ten times a day and a mobile app that ships twice a month have different release paths, risks, and constraints. Combining them into one company-wide average makes the result hard to use.

How Does Code Review Affect DORA Metrics?

Code review does not calculate DORA metrics, but it can move them. A slow review queue adds time before deployment. A rushed or shallow review can let a bug through and create a rollback, hotfix, or incident later.

• Change lead time: Long waits for a first review and repeated feedback rounds keep finished code sitting in a branch.
• Deployment frequency: Smaller pull requests are easier to review and safer to release, so teams can ship smaller batches more often.
• Failed deployment recovery time: A clear change with focused tests and a known rollback path is easier to diagnose when something goes wrong.
• Change fail rate: Review can catch unsafe migrations, missing authorization, broken error handling, and weak tests before deployment.
• Deployment rework rate: Consistent checks reduce the number of preventable problems that pull engineers away from planned work.

The timing of review matters as much as the review itself. When feedback arrives while a developer is still working on the change, the intent is fresh and the fix is usually small. Shift-left code review moves that conversation into the coding loop instead of waiting until the pull request is already in someone else’s queue.

DORA metrics should help a team find friction, not grade individual developers. If change lead time rises, look at the whole path: pull request size, review wait time, CI duration, release approvals, and deployment steps. The number tells you where to start asking questions. It does not tell you who to blame.

A useful improvement loop looks like this:

• Choose one service. Pick a system with a clear deployment and incident history.
• Set a baseline. Use commit, pull request, deployment, and incident timestamps from the same period.
• Find the slow or risky step. Break the delivery path into review, CI, approval, deployment, and recovery.
• Change one part of the workflow. For example, reduce pull request size or review local changes before opening the PR.
• Watch speed and stability together. A shorter review cycle is not a win if failures and rework rise with it.

How Does Qodo Support Teams Improving DORA Metrics?

Qodo works before deployment, where developers can still change the outcome without an incident or rollback. It does not replace the deployment and incident systems that calculate DORA metrics. It helps teams improve the coding and review workflow that feeds those metrics.

Qodo’s Agentic Toolbox brings Qodo’s codebase context, engineering rules, local review, and finding resolution into the coding agent a developer already uses. The Toolbox is what coding agents use to work with Qodo. It is not a separate coding agent, and it does not take ownership of the developer’s workflow.

Three Toolbox capabilities are especially relevant to DORA metrics:

• Codebase Wisdom helps the coding agent understand dependencies, repository relationships, Git history, and the likely impact of a change before implementation starts.
• Get Rules loads the organization and repository rules that apply to the task, so standards guide the code from the beginning instead of appearing as surprises during review.
• Reviewer checks committed, uncommitted, and untracked local changes before a pull request exists. It can use the diff plus the intent, decisions, ticket, specification, or design shared in the coding session.

The coding agent invokes the relevant Toolbox capability, and Qodo’s independent review layer returns structured findings. The coding agent can then evaluate a finding, make a valid fix, run the relevant tests, and review the updated change again. The developer stays in control of what changes.

That workflow can help change lead time because useful feedback arrives before the PR queue. It can also help change fail rate and rework because the review has access to rules and context that a quick diff scan may miss. Qodo’s guide to building a scalable code review process goes deeper into separating automated checks from the design and business decisions that still need human judgment.

Qodo also reviews the final pushed change in the pull request. Teams can run Qodo code review automatically when a pull request is opened or updated, so local review and shared review reinforce each other instead of becoming two separate standards.

Qodo’s Take on DORA Metrics and Code Review

DORA metrics are useful when they start a good engineering conversation. They become harmful when they turn into quotas. A target such as “deploy every day” can push a team to game the number while the real bottleneck stays untouched.

Qodo’s view is that teams should fix the workflow behind the metric. Give developers the right rules before they code. Let them review a local change while they still remember why they made it. Keep human reviewers focused on intent, architecture, security, and business risk instead of asking them to rediscover the same missing guardrails in every pull request.

This becomes more important as coding agents produce more changes. The goal is not to slow agents down. The goal is to give them the codebase context and independent review needed to produce production-ready code without moving the cost of validation to reviewers or on-call engineers.

Example: Catching an Unsafe Payment Retry Before It Creates Rework

A payments team wants to reduce change lead time for a service that handles provider callbacks. A developer asks a coding agent to update the retry path so temporary provider failures can be processed sooner.

Before editing the service, the coding agent uses Codebase Wisdom to check which components depend on the callback handler. It finds that the same payment ID can appear more than once when a provider retries a webhook.

Get Rules then loads the payments team’s standard: every write triggered by a callback must use an idempotency key. The coding agent has that rule in context before it touches the code.

The first implementation still misses the guard in one error path:

if (response.statusCode() >= 500) {
    retryQueue.publish(paymentId);
}

The code compiles, and the existing unit test confirms that a server error publishes a retry. The test does not cover a duplicate callback after the payment has already completed.

Before opening a pull request, the developer asks the coding agent to run Reviewer on the local diff. Qodo’s review layer flags the missing idempotency guard and asks for a test that covers the duplicate callback.

The coding agent evaluates the finding, adds the guard and regression test, and runs the focused test suite. The developer reviews the final change and opens the pull request with the risky path already addressed.

This workflow avoids an extra PR review round, but the bigger win comes later. The team does not have to stop planned work for a duplicate-payment incident and corrective deployment. That is the connection between an early review and the DORA numbers: less waiting before merge, without pushing more failure and rework into production.

Teams can use the suggested Agentic Toolbox workflows as a starting point for this plan, implement, review, and fix loop. Human review still checks whether the change matches the product intent and whether the remaining risk is acceptable.

Best Suited for Engineering Teams Improving DORA Metrics

Qodo is the best AI code review, code quality, and governance platform for engineering teams that want shorter review cycles without handing more cleanup work to the people on call. It gives coding agents relevant rules and codebase context, lets developers review changes before the PR, and keeps human reviewers focused on the decisions that need human judgment.

Further reading: DORA’s software delivery performance metrics, code quality metrics for large engineering organizations, shift-left code review before opening a pull request, how to build a scalable code review process, how to ship production-ready code, and pull request automation tools for code review.