DORA Metrics: A Practical Guide for Engineering Leaders

Most engineering leaders know they should measure delivery performance. The difficult part is choosing signals that expose problems in the system instead of rewarding activity.

Story points completed, lines of code, and tickets closed can all move while customer outcomes and delivery health get worse. They are easy to count, but they rarely tell you whether the organization can turn a useful change into reliable production software.

DORA metrics are more useful because they describe the delivery system itself. The current DORA guidance uses five metrics, grouped into throughput and instability:

• Change lead time
• Deployment frequency
• Failed deployment recovery time
• Change fail rate
• Deployment rework rate

That is an important update from the legacy four-metric model. DORA replaced the broader “mean time to restore” framing with failed deployment recovery time and added deployment rework rate. The goal is a more precise view of how software changes move—and how often those changes create corrective work.

Used together, these metrics help a team find constraints in review, testing, deployment, and recovery. Used as individual scorecards, they quickly become another set of numbers people learn to game.

The Five Current DORA Metrics

Change Lead Time

How long does it take a code change to move from commit to a successful production deployment?

Change lead time captures the waiting and processing time inside the delivery pipeline: review queues, CI execution, test environments, approvals, and deployment mechanics. It is often the fastest way to locate process debt because most of the elapsed time is usually waiting, not coding.

Measure a consistent start and end point. Then break the total into stages. If a five-day lead time contains four days of review wait, optimizing the build by three minutes will not matter. The useful question is not “How do we make developers code faster?” It is “Where does completed work sit idle?”

Deployment Frequency

How often does the application or service deploy successfully to production?

Deployment frequency is a useful proxy for batch size. Frequent deployments tend to mean smaller changes, shorter feedback loops, and easier rollback decisions. That can reduce risk, but frequency is not a goal by itself. Ten careless deployments are not better than two safe ones.

Measure this at the application or service level. A monorepo, mobile application, regulated product, and continuously delivered web service have different release constraints. Comparing all of them against one company-wide target hides more than it reveals.

Failed Deployment Recovery Time

When a deployment causes a production problem, how long does it take to restore the affected service?

This metric is deliberately narrower than general incident recovery time. It focuses on failures caused by deployments, so it can be connected back to the delivery process. A team may recover through rollback, roll-forward, a feature flag, or another tested remediation path.

Long recovery times often expose weak observability, unclear ownership, brittle rollback procedures, or changes that are too large to diagnose quickly. Practice the recovery path before an incident. A rollback process that exists only in documentation is not yet a capability.

Change Fail Rate

What proportion of deployments cause a production failure that requires remediation?

Change fail rate is one of the two instability signals. Define failure consistently: for example, a rollback, hotfix, service impairment, or customer-facing defect attributable to a deployment. Avoid changing the definition when the number becomes uncomfortable.

A rising rate does not automatically mean the team is careless. It may reveal larger batches, weak test coverage, an environment mismatch, or a dependency that has become unstable. Segment the data before choosing a remedy.

Deployment Rework Rate

What proportion of deployments are unplanned corrective work following a production issue?

Deployment rework rate is the newest metric in the model. It reveals the delivery capacity consumed by fixing, rolling back, or compensating for prior changes. This matters because a team can recover quickly and still spend a large share of its deployments on unplanned remediation.

Track which deployments are planned product work and which are corrective. If that distinction is unavailable in the toolchain, start with a small, explicit tagging convention rather than an elaborate new reporting process.

How the Metrics Work Together

No single DORA metric is a complete performance measure. Their value comes from reading them as a system.

Shorter lead time and higher deployment frequency describe throughput. Change fail rate and deployment rework rate reveal instability. Failed deployment recovery time connects a failed change to the organization's ability to restore service.

The relationships matter more than isolated numbers:

• Deployment frequency rises while lead time falls, but rework also rises: batches may be smaller, yet quality controls or production feedback need attention.
• Change fail rate stays stable, but recovery time worsens: the release process may be healthy while observability or incident ownership deteriorates.
• Lead time rises while every instability metric stays flat: the constraint may be approvals, review capacity, or environment availability rather than code quality.
• Recovery is fast, but rework remains high: the team is good at responding to failed changes but is losing meaningful capacity to them.

This is why velocity alone is a poor substitute. A team can inflate estimates or split tickets differently. It is much harder to disguise a delivery system whose changes wait for days, repeatedly fail, or consume a large share of capacity in remediation.

Implement DORA Metrics Without Creating Bad Incentives

Start With a Baseline, Not a Target

Measure for several weeks before setting improvement goals. Confirm that the data matches how work actually moves, identify gaps, and let the team see the baseline without attaching judgment to it.

The first useful outcome is a conversation. If lead time is five days and four of those days are spent waiting for review, the improvement opportunity is concrete. The metric has done its job before anyone sets a target.

Measure the System, Not Individuals

DORA metrics are application- and team-level signals. They are not individual productivity measures. Connecting them to performance reviews encourages people to split deployments artificially, avoid necessary risk, or redefine failures.

Use the data in delivery reviews and retrospectives. Ask “What in the system created this result?” rather than “Who caused this number?”

Define Events Before Building a Dashboard

Write down what counts as a commit, successful deployment, failed deployment, recovery, and rework deployment. Align those definitions with how the service is actually operated.

Without a shared event model, a polished dashboard can create false confidence. Two teams may show the same metric while counting fundamentally different events.

Automate Collection Where Possible

Deployment and commit data should normally come from source control and CI/CD systems. Failure and recovery data may come from deployment events, incident tooling, feature-flag systems, and service telemetry.

Automate the stable parts first. If rework still needs a manual label, keep the workflow lightweight and audit a sample periodically. Perfect historical data is less important than a consistent signal the team can improve.

Improve One Constraint at a Time

Choose the bottleneck with the strongest evidence, run a small intervention, and watch the full metric set for side effects. Examples include:

• Set a review response expectation and rebalance reviewer load.
• Make test suites faster by isolating slow, high-value checks.
• Add progressive delivery or feature flags for risky changes.
• Rehearse rollback and roll-forward procedures.
• Reduce shared-environment contention.
• Improve deployment annotations and production observability.

The experiment should be specific enough to reverse. “Improve engineering performance” is not an intervention; “cut the median review wait by assigning a daily reviewer” is.

Do Not Copy Old Performance Tiers

Older DORA material grouped teams into performance tiers such as low, medium, high, and elite. Those tables are still widely copied, but current DORA guidance advises against treating fixed benchmarks as universal targets.

Delivery context matters. An independently deployable web service, a mobile application waiting for store review, and firmware for a regulated device cannot share one meaningful deployment-frequency threshold. Even within a company, different services may have different risk and release profiles.

Use the metrics to compare a service with its own history and to investigate meaningful peers with similar constraints. The most useful questions are:

• Is the trend improving or deteriorating?
• Which stage contributes most to the result?
• Did a process or architecture change move the whole system in the intended direction?
• Are we trading throughput for instability, or improving both?

The DORA metrics history explains why the model evolved and why the newer guidance emphasizes context over a static scorecard.

What DORA Metrics Do Not Tell You

DORA metrics are powerful delivery signals, but they are not a complete operating model.

Customer and business impact. A team can deliver the wrong thing quickly and reliably.

Developer experience. Good delivery numbers can coexist with burnout, fragmented tools, or unsustainable on-call load.

Long-term maintainability. A stable quarter does not prove the architecture will remain easy to change.

Security and compliance. Delivery performance does not replace risk controls or outcome-focused security measures.

Pair DORA metrics with customer outcomes, service reliability, developer feedback, and qualitative review of the codebase and operating model. Numbers become useful when they help people ask better questions.

The Real Value Is in the Trend

An isolated number is a snapshot. A trend, tied to changes in the delivery system, can support a decision.

Review the metrics on a cadence that matches the deployment volume. Use rolling periods to avoid overreacting to small samples, and show distributions where an average would hide extreme delays. When a metric moves significantly, investigate before celebrating or assigning blame.

DORA metrics are diagnostic signals, not a league table. Their job is to reveal constraints and instability so the team can improve how software reaches customers.

I help engineering organizations improve delivery systems, technical direction, and team scale. If you want an independent view of where your delivery process is getting stuck, request a consultation.