DORA metrics in 2026: how to actually move the numbers

The Four Numbers That Define Your DevOps Performance

In 2014, DORA (DevOps Research and Assessment) began the largest longitudinal study of software delivery performance ever conducted. Their finding, replicated across thousands of teams and nearly a decade of data: four metrics predict both software delivery performance and organizational outcomes better than any other measure.

Those four metrics are:

• Deployment Frequency — how often you deploy to production
• Lead Time for Changes — how long from code commit to running in production
• Change Failure Rate — what percentage of deployments cause a production incident
• Mean Time to Recovery (MTTR) — how long to restore service after an incident

Teams that score elite on all four metrics deploy 973x more frequently, recover from incidents 6,570x faster, and have 3x lower change failure rates than low performers. These aren’t marginal differences — they’re order-of-magnitude gaps.

What “Elite” Performance Looks Like in 2026

DORA’s 2025 benchmarks define four performance tiers:

Most engineering teams self-assess as “high” or “medium” performers — and their actual metrics tell a different story. The gap between perceived and actual performance is itself a red flag.

Why Most Teams Don’t Track These

The honest reason: measuring DORA metrics requires instrumentation that most teams haven’t built. Deployment frequency requires a deployment event log. Lead time requires correlating commits with deployment timestamps. Change failure rate requires defining what “failure” means and tagging incidents back to deployments. MTTR requires incident timestamps with start and end.

None of this is hard to collect. But it requires deliberate setup, and most teams deprioritize measurement in favor of shipping features.

The result: teams make process changes without knowing if they’re working. They adopt a new CI/CD tool, a new branching strategy, or a new on-call rotation — but never verify that the change moved the metrics.

See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →

How to Measure Each Metric

Deployment Frequency

What to track: The number of deployments to production per day/week/month.

Data source: Your deployment pipeline. Every successful deploy to production event should be logged with a timestamp.

Common mistake: Counting deployments to staging or QA. DORA metrics measure production deployments only. Staging deploys are irrelevant.

Anti-pattern: Teams with long release cycles often “batch” multiple features into monthly releases to avoid this metric looking bad. This is exactly backwards — batching increases lead time and change failure rate. The metric is telling you something important.

Lead Time for Changes

What to track: Time from first commit on a branch to that code running in production.

Data source: Git (commit timestamps) + deployment pipeline (deploy timestamps). Correlate by commit SHA.

Common mistake: Measuring from PR creation rather than first commit. Work that sits in a branch for a week before a PR is opened should count toward lead time.

Nuance: Measuring at the commit level is more accurate but harder to implement. Many teams start by measuring from PR merge to production deploy — this undercounts lead time but is better than nothing.

Change Failure Rate

What to track: Percentage of deployments that result in a production incident (rollback, hotfix, or outage).

Data source: Your incident management system. Tag every incident with the deployment that caused it.

Common mistake: Only counting full outages. A deployment that requires a hotfix within 24 hours is a failed change, even if the service stayed up. Partial outages, performance degradation, and data quality issues all count.

Benchmark reality check: If your change failure rate is below 1%, you’re probably under-counting failures, not actually performing at elite level.

Mean Time to Recovery (MTTR)

What to track: Time from production incident detection to service restoration.

Data source: Your alerting system (incident start timestamp) and incident management system (incident resolution timestamp).

Common mistake: Measuring MTTR only for “major” incidents. Small incidents have MTTRs too — and they’re often faster to improve.

How to Move Each Metric

Improve Deployment Frequency

Deployment frequency is a proxy for two things: how small your changes are and how automated your pipeline is. To improve it:

• Break work smaller. A feature that ships in 5 PRs deploys 5x more frequently than one that ships in 1 PR — and each deployment is safer.
• Remove manual gates. Every human approval in your deployment pipeline caps your deployment frequency at human working hours.
• Automate everything before production. Tests, security scans, compliance checks — all automated and fast.

Reduce Lead Time

Long lead times usually mean one of three things: large batch sizes, slow CI pipelines, or manual approval queues.

• Optimize CI pipeline duration. A 45-minute test suite makes daily deploys painful. Target under 10 minutes for the feedback loop that matters to developers.
• Eliminate approval queues. Change advisory boards that review every deployment are a lead time multiplier. Replace human gates with automated policy checks.
• Ship smaller. Lead time correlates with PR size. Smaller PRs review faster, test faster, and deploy faster.

Cut Change Failure Rate

High change failure rates are almost always a testing and observability problem.

• Add automated security and regression checks to the pipeline. Catching a bug in CI takes minutes. Catching it in production takes hours.
• Use canary deployments. Deploy to 5% of traffic first. If error rates spike, roll back before 95% of users see the problem.
• Feature flags. Deploy code without activating it. Activate gradually. Roll back without a deployment.

Improve MTTR

MTTR improvement is pure incident response engineering.

• Reduce detection time. You can’t recover from an incident you don’t know about. Alert on symptoms (latency, error rates) not just causes (CPU, memory).
• Automate rollback. If a deployment causes a health check to fail, roll it back automatically. Don’t wait for a human to diagnose and decide.
• Runbooks as code. Documented, tested runbooks reduce MTTR by eliminating “what do I do?” time during incidents.

How IAN Connects to DORA

IAN contributes directly to three of the four DORA metrics:

• Change Failure Rate — every deployment is scanned for security vulnerabilities, compliance drift, and cost anomalies before it ships. Fewer bad deploys = lower CFR.
• Lead Time — automated fix PRs for security and compliance findings remove the manual remediation step that sits between “finding detected” and “finding resolved.”
• MTTR — real-time cost and security anomaly detection shortens the gap between “something is wrong” and “we know why.”

For teams actively tracking DORA metrics, IAN exposes deployment audit data via API, so you can feed deployment-level security and compliance findings into your existing DORA dashboard.

Start Measuring

You can’t improve what you don’t measure. Instrument your deployment pipeline this week with timestamps for each production deploy. Add incident tracking that records start and end times. In 30 days, you’ll have real baseline numbers — and a clear picture of where to focus.

Get a free infrastructure audit → | See pricing →