DORA Metrics 2026

Deployment frequency, lead time, MTTR, change failure rate.

The four DORA metrics

DORA boils down to four metrics: deploy frequency, lead time for changes, change failure rate, and mean time to restore. Each captures a different aspect of release discipline; together they triangulate engineering health.

• Deploy frequency. Deploys per day or week per team; captures release cadence.
• Lead time for changes. Commit-to-production duration per change; captures process latency.
• Change failure rate. Percentage of deploys that cause incidents per team; captures release quality.
• Mean time to restore. Recovery-time metric per team; captures incident response capability.

Performance levels

Four performance tiers anchor the comparison. Elite, high, medium, low; each has thresholds across all four metrics, and elite teams hit the bar on every metric, not just one.

• Elite. Multiple deploys per day, under-1-day lead time, 0-15% CFR, under-1-hour MTTR.
• High. Weekly-to-daily deploys, 1-day-to-1-week lead time, 0-15% CFR, under-1-day MTTR.
• Medium. Weekly-to-monthly deploys; lead time and MTTR scale up similarly.
• Low. Less than monthly deploys; teams that should be in a higher tier surface here through honest measurement.

Measure honestly

Honest measurement is the discipline. Pull from tooling not surveys, per-service not org-aggregate, and document the methodology so the numbers stay comparable across quarters.

• Pull from tooling. CI/CD and incident-tool source per metric; self-reported numbers drift up over time.
• Per service, not org-aggregate. Service granularity surfaces team-level problems; aggregates hide them.
• Consistent exclusions. Documented exclusion criteria per org; transparency about methodology beats inflated numbers.
• Quarterly methodology audit. Data-source review per quarter; catches measurement drift before it skews trend lines.

Levers for improvement

Each metric responds to different levers. Lead time wants smaller PRs and faster CI; frequency wants feature flags and decoupled deploys; CFR wants better testing and canaries; MTTR wants runbooks and observability.

• Lead time levers. Trunk-based development, smaller PRs, faster CI; reduces commit-to-prod time.
• Frequency levers. Feature flags, automated approvals, decoupled deploys; removes deploy friction.
• CFR levers. Better tests, canary deploys, automated rollback; catches issues before users see them.
• MTTR levers. Runbooks, observability, on-call training; recovers faster when issues do reach production.

How to use DORA in 2026

Use DORA as a trend tool, not an absolute scorecard. One metric improvement per quarter, trend over absolute numbers, and refusing to game the measurement keeps the program honest.

• One metric per quarter. Focused improvement per quarter; trying to optimise all four at once produces no gains on any.
• Trend over absolute. Quarter-on-quarter improvement is the signal; absolute numbers depend on context that does not transfer.
• Do not game the metrics. No-CFR-by-hiding-incidents rule; teams that game lose trust and damage the program.
• Published team metrics. Visible scorecard per team per quarter supports honest improvement conversations rather than executive theatre.