Key DevOps Metrics to Track: The 5 DORA Metrics + 6 That DORA Misses (2026)

TL;DR: The 4 DORA metrics became 5 in 2024 with the addition of deployment rework rate. But only 19% of engineering teams qualify as elite performers, while the low-performance tier grew from 17% to 25% year on year (DORA State of DevOps 2024). Elite teams deploy 182 times more frequently than low performers, with lower failure rates and faster recovery simultaneously. Tracking DORA alone misses six operational metrics that explain why two teams with identical DORA numbers can have completely different engineering health.

Why Most DevOps Metric Conversations Start (and Stop) at DORA

DORA metrics are the closest thing the software engineering industry has to a standard for measuring delivery performance. Four (now five) data points, backed by a decade of research across 39,000+ technology professionals, that correlate directly with organizational performance outcomes.

The problem with most DevOps metric guides: they present DORA benchmarks as the destination rather than the diagnostic. A team that knows its deployment frequency is “medium tier” has a category, not a plan. A team that understands what is driving that number, and what additional signals reveal about incident patterns, infrastructure cost, and engineering satisfaction, has a diagnosis.

This guide covers all five DORA metrics with their 2024 benchmarks, the critical update that the 2025 DORA research made to the tier system itself (which most coverage has ignored), and six operational metrics that DORA’s framework explicitly does not capture but that elite teams track alongside it.

The performance gap that makes this matter:

182 times. Elite DORA performers deploy 182 times more frequently than low performers (DORA State of DevOps 2024). This is not a marginal difference in tooling sophistication. It reflects a fundamentally different relationship with the codebase, the deployment pipeline, and the definition of “done.” Elite teams at that frequency also have lower failure rates and faster recovery times, not higher. The practices that drive throughput are the same practices that drive stability.

The widening gap, low-performance tier growing from 17% to 25% of the survey population in 2024 while only 19% of teams are elite, suggests the industry is splitting: teams investing in the right practices are pulling ahead, and teams that are not are falling further behind.

The 5 DORA Metrics: Definitions, Benchmarks, and What They Actually Measure

Metric 1: Deployment Frequency

What it measures: How often your team successfully releases to production. Not commits, not merges, not CI runs. Production deployments specifically.

Why it matters: Deployment frequency is a proxy for batch size. Teams that deploy frequently deploy small changes. Small changes are easier to test, easier to review, easier to roll back, and carry less risk per deployment. The act of deploying frequently forces the automation, test coverage, and release process maturity that makes frequent deployment safe.

2024 DORA benchmarks:

What to measure: Production deployments per day, week, or month. A “deployment” must be consistently defined across teams. Define it as code reaching the production environment and serving user traffic, not a merge to main or a staging deployment.

The AI risk with this metric: When AI coding assistance raises the volume of code being written, deployment frequency can climb without the underlying delivery system becoming healthier. A team deploying more frequently because AI writes faster, without improving test automation or PR review depth, is shipping bugs faster. Always pair deployment frequency with change failure rate.

Metric 2: Lead Time for Changes

What it measures: The time from a developer’s first commit on a branch to that code running in production. The full chain: coding time, review wait time, review iteration, CI pipeline, and deployment pipeline.

Why it matters: Lead time exposes where in your delivery system work is waiting rather than moving. A lead time of 3 days with 4 hours of actual work means 2.8 days of queue, not productivity. Identifying which phase dominates, review wait, slow CI, manual approval gates, determines where investment reduces lead time most.

2024 DORA benchmarks:

Lead time components to measure separately:

• PR open to first review (measures review responsiveness culture)
• PR open to merge (measures review iteration depth and speed)
• CI pipeline duration (measures automation investment)
• Merge to production (measures deployment automation maturity)

Teams that know their aggregate lead time but not which phase drives it cannot target improvements. Measure the phases, not only the total.

Metric 3: Change Failure Rate

What it measures: The percentage of deployments that cause a failure in production requiring remediation. Hotfixes, rollbacks, and patches within a defined post-deployment window all count.

Why it matters: Change failure rate is the stability counterweight to deployment frequency. A team that dramatically increases deployment frequency while change failure rate climbs has not improved. It has started shipping instability faster. Change failure rate and deployment frequency must be read together.

2024 DORA benchmarks:

One benchmark anomaly to understand: High and medium tiers overlap significantly in published DORA tables because change failure rate is the noisiest of the four metrics with the highest year-over-year variance. What distinguishes elite from high is not the rate alone but the combination: elite teams maintain 0–5% failure rate while deploying multiple times per day. High performers achieve similar rates with lower deployment frequency. The combination matters more than either number alone.

What counts as a failure: Define this precisely before measuring. A failed deployment that rolls back automatically in under 1 minute differs meaningfully from one that causes a 2-hour incident. Some teams count only customer-impacting failures; others count all rollbacks. Consistency of definition matters more than which definition you choose.

Metric 4: Time to Restore Service (TTRS)

What it measures: After a production incident is detected, how long until service is restored to users. The 2024 DORA research renamed this from “Mean Time to Recovery” to “Time to Restore Service” to clarify that it measures restoration time, not the engineering time to fix the underlying root cause.

Why it matters: TTRS is the resilience metric. A team that detects incidents quickly, escalates effectively, and can route around or roll back failures restores service in minutes. A team without on-call maturity, runbook infrastructure, and practiced incident response restores service in hours or days while user-facing impact accumulates.

2024 DORA benchmarks:

TTRS vs MTTR: The distinction matters. MTTR-as-Restore (which DORA measures) is the clock time from incident detection to service restoration. MTTR-as-Repair is the engineering time spent on the underlying fix, which may happen after the service is restored. Track both, but recognize they measure different things. DORA benchmarks apply to TTRS (restoration), not root cause fix time.

Metric 5: Deployment Rework Rate (Added 2024)

What it measures: The proportion of deployments that are unplanned work driven by production incidents: emergency fixes, hotfixes, and reverts. This is the fifth DORA metric added in the 2024 report.

Why it matters: Change failure rate tells you how often deployments cause failures. Deployment rework rate tells you what percentage of your deployment activity is reactive, fixing production problems rather than delivering planned features. A team where 30% of deployments are hotfixes is spending 30% of its delivery capacity on repair, not progress.

2024 benchmarks: DORA has not yet published universal tier thresholds for deployment rework rate as of the 2024 report. The metric is tracked but the tier classification is still being refined. Use your own baseline trend as the benchmark: the goal is a lower rework rate over time.

How to measure: Tag deployments at release time as planned (feature, improvement) or unplanned (hotfix, revert, emergency fix). The percentage of unplanned deployments over a rolling 30-day window is your deployment rework rate.

The 2025 DORA Update Most Coverage Has Missed

The 2025 DORA State of DevOps report made a significant methodological change: it retired the four-tier Elite-to-Low performance classification and replaced it with seven team archetypes defined by the intersection of delivery performance and human factors, including burnout, organizational friction, and sustainability of pace.

This is not a footnote. DORA’s own researchers concluded that ranking teams on a single four-rung ladder was flattening away the context that determines whether a team is genuinely healthy. Two teams with identical deployment frequency can be in completely different places once you account for whether that pace is sustainable.

What this means for how you use DORA benchmarks:

The tier thresholds from the 2024 report remain the most widely-cited reference points and are useful as directional orientation. But the progression to a 7-archetype model signals that delivery metrics alone do not capture engineering organization health. A team deploying 10 times per day with 3% failure rate and 30% of engineers at burnout risk is not in a better place than a team deploying twice per day with 8% failure rate and sustainable load.

The practical application: Use DORA benchmarks as a coarse check (are we in the right neighborhood?), then set improvement goals against your own baseline trend over the past two quarters. Your own trend controls for your domain, release constraints, and deployment definition in ways that industry percentiles cannot.

Perforce 2026 State of DevOps (n=800+ IT professionals) corroborates this. High-maturity DevOps organizations are 66% more likely to respond “very effectively” to production incidents and 36% more likely to automate the majority of deployments. But they achieve this without the inconsistency that plagues low-maturity teams: 78% of low-maturity organizations operate non-standardized delivery models, leading to increased rework and higher variability even when individual deployments succeed.

6 Operational Metrics DORA Does Not Cover

DORA measures how fast and how safely software reaches production. It does not measure what happens in the operational environment once software is live. These six metrics are tracked by high-performing teams alongside DORA and cover the dimensions DORA explicitly excludes.

Operational Metric 1: Mean Time to Detect (MTTD)

What DORA misses: DORA’s TTRS starts the clock when an incident is detected. MTTD measures the gap between when something fails and when the team knows about it. A team with 30-minute TTRS and 4-hour MTTD has a 4.5-hour incident duration. MTTD is where observability investment pays off.

How to measure: Time from first production symptom (first anomalous metric reading, first error spike) to first alert received by an on-call engineer. Requires your alerting system to timestamp both the anomaly and the notification.

Target: Under 5 minutes for P0/P1 incidents. Teams using ML-based anomaly detection commonly achieve 2–3 minutes. Teams relying on static threshold alerts often miss early-stage incidents for 15–30 minutes.

Operational Metric 2: CI Pipeline Duration

What DORA misses: Lead time for changes includes CI pipeline duration, but does not break it out separately. A 45-minute CI pipeline that runs on every PR is a 45-minute tax on every reviewer and every developer waiting for green. CI duration is frequently the largest single driver of medium-to-high lead time.

How to measure: Median and P95 CI run duration from test trigger to pass/fail result. Track separately for unit tests, integration tests, and E2E tests to identify where time accumulates.

Target: Under 10 minutes for unit tests; under 30 minutes for the full CI suite including integration. Beyond 30 minutes, developers context-switch away from the PR they are waiting on, compounding review latency.

Operational Metric 3: Code Review Turnaround Time

What DORA misses: Lead time includes review time but DORA does not distinguish between PR open and first review received. A 3-day lead time with 2 days of review wait indicates a culture and process problem, not a tooling problem.

How to measure: Time from PR creation to first review comment or approval. Track P50 and P95 across the engineering organization. Both ends of the distribution matter: P50 reveals the norm; P95 reveals what happens to time-sensitive fixes.

Target: Under 4 hours for P50 (most teams). Under 24 hours for P95 (exceptions). Teams at more than 1 day P50 review wait have a collaboration and workflow problem that no amount of deployment automation solves.

Operational Metric 4: Infrastructure Cost per Request (or per Deployment)

What DORA misses: DORA measures delivery performance, not delivery efficiency. A team deploying 50 times per day at $3/deployment operates differently from one deploying 50 times per day at $0.30/deployment. Infrastructure cost discipline belongs on the same dashboard as delivery metrics.

How to measure: Monthly cloud infrastructure spend divided by monthly request volume (cost per request) or divided by deployment count (cost per deployment). Track week over week for trend visibility. A rising cost-per-request while traffic is flat signals over-provisioning or architectural inefficiency.

Target: Varies by architecture and request type. The target is a stable or declining trend, not a specific number. Rising cost-per-request without a corresponding rise in feature delivery is a signal requiring investigation.

Operational Metric 5: Test Coverage on Changed Code (Delta Coverage)

What DORA misses: Change failure rate measures how often deployments cause failures but does not measure what prevented failures. Test coverage on the specific code changed in a deployment is a leading indicator of change failure rate.

How to measure: Not repo-wide coverage (which is a lagging vanity metric), but patch coverage: what percentage of lines modified in the deployment were covered by tests in the test suite that ran before merge. Tools like Codecov, Coveralls, and pytest-cov with diff mode report this per-PR.

Target: 80%+ patch coverage on changed code per PR. Below 60% is a meaningful risk signal. Repo-wide coverage percentage is less useful than per-change coverage for predicting production failures.

Operational Metric 6: On-Call Load per Engineer

What DORA misses: Time to restore service measures recovery speed but not the human cost of achieving it. An engineering team restoring service in 45 minutes because three engineers are paged at 2am every other week is in a different place than one doing it during business hours with documented runbooks.

How to measure: Average number of pages per engineer per week, hours outside normal working hours spent on incidents per quarter, and percentage of incidents resolved via runbook versus requiring escalation to senior engineers.

Target: Under 2 pages per engineer per week on average; under 10% of incident resolution requiring escalation beyond the first on-call responder. Teams above these thresholds typically see TTRS improve when on-call load decreases, not when more engineers are added to rotation.

How to Implement DevOps Metrics Without Creating a Metrics Theater

The most common failure mode when implementing DevOps metrics is creating dashboards that engineering teams optimize for rather than learn from. A team that knows its deployment frequency is being tracked will find ways to deploy more frequently, including deploying smaller meaningless changes. A team that knows its change failure rate is watched will find ways to not classify failures as failures.

The implementation sequence that avoids metrics theater:

Step 1: Establish baselines before setting targets. Run your measurement tooling for 60 days without announcing any targets. Understand what your actual current state is. Teams that set targets before measuring baselines tend to anchor to aspirational numbers with no empirical basis.

Step 2: Measure pairs, not singles. Always track deployment frequency alongside change failure rate. Always track lead time alongside CI pipeline duration. Single metrics in isolation enable gaming; pairs create accountability across the trade-off.

Step 3: Make metrics team-visible, not manager-only. Engineering teams improve metrics they can see. A deployment frequency dashboard that only leadership reviews produces awareness at the management level but no behavioral change at the engineering level. The Atlassian State of Teams 2025 found that teams spend 25% of the workweek searching for information. That problem is upstream of every DORA metric and requires visibility, not more process.

Step 4: Use metrics to start conversations, not to evaluate individuals. DORA research explicitly states that these metrics should not be used to measure individual performance, only team and organizational performance. A developer who contributes to high change failure rate is operating in a system that allows or produces those failures. The metric identifies the system problem; it does not identify a bad developer.

Step 5: Build a tool stack that derives metrics from existing data. Manual metrics tracking creates measurement overhead that defeats the purpose. GitHub, GitLab, and Bitbucket all expose deployment and PR data via API. PagerDuty and OpsGenie export incident data. CI/CD systems (GitHub Actions, CircleCI, Jenkins) log pipeline durations. Good metrics tooling derives DORA metrics from existing data sources rather than requiring manual entry.

Tooling options by scale:

• Small teams, starting out: Linear/Jira + GitHub API, custom dashboard in Grafana or Datadog
• Mid-market: Sleuth, LinearB, or Faros.ai aggregating across CI, git, and incident management
• Enterprise: DORA’s own Four Keys open-source project (BigQuery-backed) or CI/CD Watch (SaaS, multi-provider)

The Connection Between DevOps Metrics and AI Adoption

70% of organizations report that DevOps maturity meaningfully influences their AI success (Perforce 2026 State of DevOps, n=800+ IT professionals). 72% of leaders in high-maturity organizations report deeply embedded AI practices, compared to just 18% in low-maturity counterparts.

This correlation matters for how you prioritize DevOps metric improvement. Teams that have not solved basic delivery hygiene, deployment automation, test coverage, review processes, before adopting AI coding assistance, see AI raise certain metrics without improving others. GitHub Copilot research shows developers complete tasks 55% faster with AI assistance, which directly affects deployment frequency and lead time for changes. But 55% faster coding without proportionate improvement in review processes, test automation, and deployment reliability accelerates throughput without improving stability.

The Stride 2026 DORA pre-registration research hypothesizes that AI adoption raises change failure rate in non-elite quartiles while not affecting it in elite quartiles. The directional prediction: teams with mature delivery practices absorb AI-generated code safely; teams without those practices ship AI-generated failures at higher velocity.

What this means for metric prioritization: If your change failure rate is above 15% and you are introducing AI coding assistance, prioritize change failure rate improvement before expanding AI tool adoption. Adding velocity to an unstable system amplifies instability.

How InApps Implements DevOps Metrics for Engineering Teams

InApps implements DevOps metric programs as part of the DevOps Consulting engagement, embedded with a dedicated DevOps engineer inside the client’s sprint process.

The InApps implementation approach:

The engagement starts with a metric baseline sprint: 30 days of automated data collection from existing CI/CD systems, git platform, and incident management, producing a baseline across all 5 DORA metrics and the 6 operational metrics above. No manual tracking, no new tools required in most cases.

From the baseline, the InApps engineer identifies the two or three metrics with the widest gap to the high-performance tier and the clearest root cause. Deployment frequency low because releases require manual approval? The fix is CI/CD automation. Change failure rate high because integration test coverage is inadequate? The fix is test infrastructure. Review turnaround high because PRs are too large? The fix is PR size policy and review culture.

Most teams see measurable improvement in their two priority metrics within one sprint cycle after identifying root causes against a baseline.

What Perforce’s 2026 data confirms: High-maturity DevOps organizations are 36% more likely to automate the majority of deployments and 66% more likely to respond very effectively to production incidents. Both outcomes come from the same investment in delivery infrastructure, not from tracking metrics more carefully.

A dedicated DevOps engineer at InApps Vietnam rates ($50–$75/hr) embedded in your sprint process implements the automation, observability, and process changes that move metrics. A consultant who reviews your dashboard and produces recommendations does not.

InApps engineers are based in Vietnam (UTC+7), providing full timezone overlap with Australian teams and async-compatible workflow for US and UK teams, working inside the client’s sprint process rather than as external advisors reviewing outputs.

Request a DevOps metrics baseline audit, InApps maps your current delivery performance across all 5 DORA metrics and 6 operational metrics before any scope is committed.

Frequently Asked Questions

What are the key DevOps metrics to track?

Five DORA metrics: deployment frequency, lead time for changes, change failure rate, time to restore service, and deployment rework rate (added 2024). Plus six operational metrics DORA does not cover: MTTD (mean time to detect), CI pipeline duration, code review turnaround time, infrastructure cost per request, test coverage on changed code, and on-call load per engineer. DORA measures delivery speed and stability; the operational metrics explain what happens after code reaches production.

What are the DORA metrics elite benchmarks in 2026?

Based on the 2024 DORA State of DevOps research: deployment frequency = multiple times per day; lead time for changes = less than 1 day (elite teams: under 1 hour); change failure rate = 0–5%; time to restore service = less than 1 hour; deployment rework rate = no published tier threshold yet. Only 19% of teams qualify as elite across these metrics. Elite teams achieve all four metrics simultaneously, not by excelling in one at the expense of others.

What changed in the 2025 DORA report?

The 2025 DORA research retired the four-tier Elite/High/Medium/Low classification and replaced it with seven team archetypes defined by the intersection of delivery performance and human factors including burnout and organizational friction. This reflects the finding that two teams with identical DORA numbers can be in very different places based on whether the pace is sustainable. The 2024 tier benchmarks remain widely used as directional reference points.

How do you measure DevOps metrics without creating gaming incentives?

Always measure pairs, not singles. Deployment frequency with change failure rate. Lead time with CI pipeline duration. Teams that know only deployment frequency will deploy meaningless changes. Teams that know both cannot increase frequency without checking stability. Use metrics to start conversations about system problems, not to evaluate individual engineers. DORA research explicitly warns against using these metrics for individual performance review.

How often should you review DevOps metrics?

Deployment frequency and CI pipeline duration: weekly. Lead time and change failure rate: biweekly sprint review cadence (same as other engineering metrics). Time to restore service: review after every incident plus monthly aggregate. On-call load: monthly. Cloud cost per request: weekly. The review cadence should match the cadence at which the team can act on the findings.

Should AI coding tools change which DevOps metrics I prioritize?

Yes. If you are introducing AI coding assistance to a team where change failure rate is above 15%, prioritize change failure rate improvement first. AI tools raise the volume and speed of code creation, which improves deployment frequency and lead time. But without proportionate investment in test automation and review quality, higher velocity produces higher failure rates. The 2026 Perforce State of DevOps found that 70% of organizations believe DevOps maturity meaningfully influences their AI success, and 72% of leaders in high-maturity orgs report deeply embedded AI practices versus 18% in low-maturity counterparts.

What is deployment rework rate and why was it added to DORA?

Deployment rework rate measures the proportion of deployments that are unplanned work driven by production incidents: emergency fixes, hotfixes, and reverts. Added in the 2024 DORA report as the fifth metric. Change failure rate measures how often deployments cause failures. Deployment rework rate measures what percentage of your total deployment activity is reactive, repair rather than progress. A team where 30% of deployments are hotfixes is spending 30% of delivery capacity not on features but on fixing production.

Key Takeaways

• 5 DORA metrics in 2026: deployment frequency, lead time for changes, change failure rate, time to restore service, and deployment rework rate (added 2024). Most articles still cover only 4.
• Only 19% of teams are elite performers (DORA 2024). The low-performance tier grew from 17% to 25% year on year. The gap is widening.
• 182x deployment frequency gap between elite and low performers (DORA State of DevOps 2024). Elite teams also have lower failure rates and faster recovery simultaneously.
• The 2025 DORA shift matters: 4 performance tiers replaced by 7 archetypes incorporating human factors including burnout and sustainability. Two teams with identical DORA numbers can be in completely different places.
• Read metrics in pairs: deployment frequency with change failure rate; lead time with CI pipeline duration. Single metrics enable gaming.
• 6 operational metrics DORA does not cover: MTTD, CI pipeline duration, review turnaround, infrastructure cost per request, patch coverage, on-call load. High-performing teams track all 11.
• AI without delivery maturity amplifies instability. 70% of organizations say DevOps maturity influences AI success (Perforce 2026, n=800+). Solve change failure rate before expanding AI coding assistance.
• Baseline before target. Run measurement tooling for 60 days without announcing targets. Understand actual current state before anchoring to aspirational numbers.
• High-maturity DevOps teams are 66% more likely to respond very effectively to production incidents and 36% more likely to automate the majority of deployments (Perforce 2026).