Summary
- DevOps is a practice, and DORA is the measurement system that tells you whether the practice is working.
- Elite deploy frequency runs above 1.2 releases per service; elite deploy time is under 16 hours at the 75th percentile, per LinearB's 2026 Benchmarks Report.
- Deploy time has the widest spread of any delivery metric: under 16 hours at elite, beyond 277 hours in the lowest tier, so automation pays off most here.
- Elite change failure rate sits under 1%, so a deploy frequency gain that pushes change failure rate up is a cost shift rather than an improvement.
- MTTR left the 2026 published benchmarks since teams measure recovery from different starting points; track it against your own trend instead.
DevOps and the four measures that show whether it works
Elite DevOps teams deploy above 1.2 times per service and keep change failure rate under 1%, according to LinearB's 2026 Software Engineering Benchmarks Report, built from more than 8.1 million pull requests from 4,800 teams across 42 countries. DevOps is the practice of joining development and operations around shared ownership of delivery, using automation to shorten the path from commit to release, and those bands are how you tell whether the practice is working in your organization. Deploy time carries the widest spread of any delivery metric, running from under 16 hours at elite to beyond 277 hours in the lowest tier. This page covers the four DORA measures, the 2026 band for each, and why one long-standing DevOps metric left the published set this year.
DORA supplies the vocabulary these bands are expressed in, so start there if you want the metric definitions before the practice. See DORA metrics.
DevOps is the practice of joining development and operations around shared ownership of delivery, using automation and measurement to shorten the path from commit to production. The four DORA measures give the practice its scoreboard, and deploy frequency plus change failure rate are the pair that show whether speed and stability moved together.
What DevOps covers, and what it does not
DevOps covers the pipeline, the automation around it, and the ownership model that keeps one team responsible from commit through release. Continuous integration and continuous delivery are the mechanisms, shared on-call and blameless review are the cultural half, and the measurement layer is what stops the practice becoming a set of tool preferences. What DevOps does not cover is the work upstream of the commit, including planning accuracy, review capacity, and the question of whether the change was worth building.
The boundary matters because the 2026 data shows the constraint sitting upstream of deployment for a large share of teams. Pull requests created by AI agents wait 17.6 hours before review at the 75th percentile against 3.4 hours for unassisted pull requests. A pipeline that deploys in minutes cannot compensate for a review queue that takes a day. For the pipeline tooling itself, see CI/CD tools.
What to do next: Check whether your slowest delivery phase sits inside the DevOps boundary. If the delay is in pickup or review, a pipeline investment will not move your cycle time.
The four DORA measures and their 2026 bands
DORA reduced delivery performance to four measures, and three of them appear in the 2026 published benchmarks with bands you can compare against. The table maps each DORA measure to the metric that carries it, at the 75th percentile.
| DORA measure | Benchmark metric | Elite | Good | Needs improvement |
|---|---|---|---|---|
| Deployment frequency | Deploy Frequency (per service) | > 1.2 | 1.2 - 0.5 | < 0.2 |
| Lead time for changes | Cycle Time (hours) | < 25 | 25 - 72 | > 161 |
| Change failure rate | Change Failure Rate (%) | < 1% | 1 - 4% | > 17% |
| Failed deployment recovery | Not published in 2026 | n/a | n/a | n/a |
Deploy time is the fourth number worth watching even though DORA does not name it, with elite under 16 hours and the lowest tier beyond 277 hours. Change failure rate is the guardrail on all of it, and its single band applies across every percentile, since rate metrics do not vary by percentile the way time metrics do. For the metric-by-metric view, see DevOps metrics and KPIs and how to improve change failure rate.
What to do next: Put deploy frequency and change failure rate on the same chart. Either one alone can be improved by making the other worse.
Why MTTR left the 2026 benchmarks
MTTR was removed from the 2026 published benchmarks because of definitional variance rather than a change in performance. Teams start the clock at different events, detection in one organization and customer impact in another, and they scope incidents differently, so the cross-organization comparison is not valid even when every team measures carefully. The metric still matters for operational health, and the recommendation is to track it against your own internal trend.
The removal is a useful test to apply to any metric you report externally. A metric qualifies for benchmarking when the definition holds across organizations, the data collection is consistent, and the number means the same thing in both places. Recovery time fails the first test, which is why the honest move was to drop it rather than publish a band nobody could use.
What to do next: Keep MTTR in your internal incident review and remove it from any slide that compares your team to the industry.
APEX: run DevOps as a measured loop in four steps
DevOps supplies the practice and APEX supplies the operating cadence, with efficiency and predictability as the two pillars that carry the DevOps question. Each pillar has one north star, which keeps the pipeline conversation to a small number of decisions. The full model is in the APEX framework.
- Instrument the whole path from commit to release rather than the deployment step alone, so cycle time and deploy time are both visible.
- Compare deploy frequency, cycle time, and change failure rate against the band for your organization size rather than the aggregate.
- Stabilize before accelerating. A change failure rate above 4% means the next release cadence increase will land as incidents.
- Automate the manual gate in your slowest phase, then re-measure after one full sprint before changing anything else.
Order carries the argument here. The 2025 DORA State of AI-assisted Software Development report found that AI amplifies the capability an organization already has, which means an unstable pipeline gets less reliable as throughput rises. Its companion AI capabilities model sets out the seven organizational capabilities that decide which direction the amplification runs.
What to do next: Run step three before step four this quarter. Stability first is the cheaper order, since incidents consume the capacity you were trying to create.
What DevOps maturity looks like in the data
Teams that treat the pipeline as a measured system change release behavior rather than release intentions. Syngenta cut cycle time by 81%. Yum! Brands automated 321 developer hours per month. Expedia Group ran more than 3 million automations, including over 200,000 pull request automations, and reinvested 2,000 developer hours per month. Each case followed the same sequence of instrumenting the path, finding the constraint, then automating the gate. Workflow automation is where the fourth step happens, and engineering metrics in LinearB is where the bands sit next to your own numbers.
What to do next: Pick the one approval or check in your release path that a human performs every time, and make it a policy rule this quarter.
Frequently asked questions
What is DevOps?
DevOps is the practice of joining development and operations around shared ownership of delivery, using automation and measurement to shorten the path from a code change to a working release. Continuous integration and continuous delivery are its mechanisms, and the DORA measures are its scoreboard.
What are the four DORA metrics?
The four DORA measures are deployment frequency, lead time for changes, change failure rate, and failed deployment recovery time. In the 2026 published benchmarks, the first three map to deploy frequency, cycle time, and change failure rate, with elite bands above 1.2 releases per service, under 25 hours, and under 1%.
What is a good deployment frequency?
Elite deploy frequency is above 1.2 releases per service and good is 1.2 to 0.5, according to LinearB's 2026 Software Engineering Benchmarks Report. Enterprise organizations above 1,000 employees reach elite above 0.7 per service, so compare against your size band rather than the aggregate.
Is DevOps the same as platform engineering?
No. DevOps is a practice built on shared ownership of delivery, while platform engineering is an organizational answer to it, where a dedicated team builds internal tooling so product teams get the DevOps outcome without assembling the pipeline themselves.
Why is MTTR not in the 2026 engineering benchmarks?
MTTR was removed because of definitional variance. Teams start the recovery clock at different events and scope incidents differently, so the numbers are not comparable across organizations. Track MTTR against your own internal trend instead of an industry band.
How does AI change DevOps?
AI increases the volume of code entering the pipeline without increasing review or release capacity, so the constraint moves downstream. Agentic pull requests wait 17.6 hours before review at the 75th percentile against 3.4 hours for unassisted work, which means the pipeline conversation now starts before deployment.