Engineering Delivery
DORA performance levels
DORA performance levels are the groups, usually named elite, high, medium and low, that DORA finds when it sorts survey answers about the DORA metrics. They describe how teams in that year's survey actually performed, not targets DORA set in advance. They are a useful reference point, but DORA itself says improving matters more than reaching any particular level.
If the DORA metrics are new to you, read The five DORA metrics first. This page explains where the levels come from, what the latest figures are, and how to use them without letting them do harm.
Where do the levels come from?
The levels come from a statistical method called cluster analysis, run on survey answers, so they emerge from the data rather than being decided beforehand.
Every year DORA asks people about the software delivery performance of the main application or service they work on: how long changes take to reach production, how often they deploy, and so on. Cluster analysis then groups answers that are similar to each other and different from the rest. In DORA's words: "We do not set these levels in advance, rather we let them emerge from the survey responses" (2024 report, page 13).
Two things follow from that:
- The levels change from year to year. They are a snapshot of who answered that year. The boundaries and the number of groups are not fixed.
- The names are labels, not grades. "Elite" is simply the name of the group that did best on the metrics in that survey.
The 2024 performance levels
In 2024, four clusters emerged from the survey, analysed on the original four DORA metrics so the results stay comparable with earlier years (2024 report, page 13).
| Performance level | Change lead time | Deployment frequency | Change fail rate | Failed deployment recovery time | Share of respondents |
|---|---|---|---|---|---|
| Elite | Less than one day | On demand (multiple deploys per day) | 5% | Less than one hour | 19% (18 to 20%) |
| High | Between one day and one week | Between once per day and once per week | 20% | Less than one day | 22% (21 to 23%) |
| Medium | Between one week and one month | Between once per week and once per month | 10% | Less than one day | 35% (33 to 36%) |
| Low | Between one month and six months | Between once per month and once every six months | 40% | Between one week and one month | 25% (23 to 26%) |
Source: Accelerate State of DevOps Report 2024, "Performance levels", page 13. The ranges in the last column are 89% uncertainty intervals: DORA's estimate of where the true share most likely lies, given that it surveyed a sample of people rather than everyone.
How big are the differences?
The gap between the top and bottom groups is very large. Compared with low performers, DORA reports that elite performers have (2024 report, page 15):
- 127 times faster change lead time
- 182 times more deployments per year
- 8 times lower change failure rate
- 2,293 times faster failed deployment recovery
Why does "medium" have a better change fail rate than "high"?
Look closely at the table and something seems off: medium performers report a 10% change fail rate, better than the 20% of high performers.
DORA points this out itself. The medium group is slower but more stable than the high group, and DORA "made a decision to call the faster teams 'high performers'" (2024 report, page 14). Which is better, deploying more often or failing less, depends on the application, the team's goals and above all what its users expect. DORA uses this to make a wider point: "Improving should be more important to a team than reaching a particular performance level. The best teams are those that achieve elite improvement, not necessarily elite performance."
Does industry matter?
Not much. DORA "rarely finds that industry is a predictor of software delivery performance" and sees high-performing teams in every industry (2024 report, page 15). Being in banking, healthcare or retail is not a reason to expect worse numbers.
What changed in 2025?
The 2025 report publishes no performance levels and no target figure for any metric. It publishes how answers were spread across each metric, reads the five metrics in two groups, throughput and instability, and describes seven team profiles that look at people as well as delivery.
How do you compare? The 2025 spread of answers
For each metric, the 2025 report shows what share of respondents picked each answer (2025 report, pages 20 and 21). The "this level or better" column adds up everyone at that level and above, so you can see roughly where an answer sits.
Change lead time (2025 report, page 20)
| Answer | Share | This level or better |
|---|---|---|
| Less than one hour | 9.4% | 9.4% |
| Less than one day | 15% | 24.4% |
| Between one day and one week | 31.9% | 56.4% |
| Between one week and one month | 28.3% | 84.7% |
| Between one month and six months | 13.2% | 98% |
| More than six months | 2% | 100% |
Deployment frequency (2025 report, page 20)
| Answer | Share | This level or better |
|---|---|---|
| On demand (multiple deploys per day) | 16.2% | 16.2% |
| Between once per hour and once per day | 6.5% | 22.7% |
| Between once per day and once per week | 21.9% | 44.6% |
| Between once per week and once per month | 31.5% | 76.1% |
| Between once per month and once every six months | 20.3% | 96.4% |
| Fewer than once per six months | 3.6% | 100% |
Failed deployment recovery time (2025 report, page 21)
| Answer | Share | This level or better |
|---|---|---|
| Less than one hour | 21.3% | 21.3% |
| Less than one day | 35.3% | 56.5% |
| Between one day and one week | 28% | 84.5% |
| Between one week and one month | 9.4% | 93.9% |
| Between one month and six months | 4.9% | 98.8% |
| More than six months | 1% | 100% |
Change fail rate (2025 report, page 21)
| Answer | Share | This level or better |
|---|---|---|
| 0 to 2% | 8.5% | 8.5% |
| 2 to 4% | 8.1% | 16.7% |
| 4 to 8% | 19.6% | 36.2% |
| 8 to 16% | 26% | 62.2% |
| 16 to 32% | 19.5% | 81.6% |
| 32 to 64% | 12.5% | 94.1% |
| More than 64% | 5.9% | 100% |
Deployment rework rate (2025 report, page 21)
| Answer | Share | This level or better |
|---|---|---|
| 0 to 2% | 6.9% | 6.9% |
| 2 to 4% | 5.8% | 12.8% |
| 4 to 8% | 13.7% | 26.5% |
| 8 to 16% | 26.1% | 52.6% |
| 16 to 32% | 24.7% | 77.3% |
| 32 to 64% | 15.4% | 92.7% |
| More than 64% | 7.3% | 100% |
A worked example: the booking team from our other guides has a change lead time of about 3 days. That falls in "between one day and one week", where 56.4% of respondents answered that or faster. In other words, they sit around the middle. Their change fail rate of about 17% falls in the 16 to 32% band, where about 62% answered better. That points to stability as the place to look first.
Note: these are self-reported survey answers, not measurements, and each answer is a wide band. DORA says the most insightful comparisons are for the same application or service over time (2025 report, page 20). Use the spread to get your bearings, not to set a target.
The seven team profiles
The 2025 report also found seven team profiles, using cluster analysis on eight factors at once: team performance, product performance, software delivery throughput, software delivery instability, individual effectiveness, valuable work, friction and burnout (2025 report, page 15). The idea is that delivery numbers alone cannot tell a team that is fast but burning out from one that is stable but stuck.
| Profile | Share of respondents | In plain words |
|---|---|---|
| Foundational challenges | 10% | In survival mode, with basic gaps in process, environment and results, and high burnout. |
| The legacy bottleneck | 11% | Old, unstable systems dictate the work and wear down morale. |
| Constrained by process | 17% | Systems are stable, but slow processes eat the team's effort, leading to high burnout and low impact. |
| High impact, low cadence | 7% | Produces high-impact work with strong product performance, but delivers slowly and with high instability. |
| Stable and methodical | 15% | Delivers valuable work at a deliberate, sustainable pace. |
| Pragmatic performers | 20% | Delivers with speed and stability, while well-being and engagement are about average. |
| Harmonious high-achievers | 20% | Does well across delivery, product and well-being, with low burnout and friction. |
Sources: 2025 report, pages 15 to 19. DORA notes that the names and descriptions are its interpretation of the data, and that a team may match a profile's numbers without feeling the name fits (2025 report, Figure 2).
The two strongest profiles, pragmatic performers and harmonious high-achievers, together make up nearly 40% of respondents. DORA reads this as strong evidence that the "speed vs. stability" trade-off is a myth: the best teams excel at both (2025 report, page 19).
DORA publishes no rule for placing one team in a profile from its numbers. Team profiles explains how DORA suggests a team finds its own, and why the app shows none.
How should you use benchmarks?
Use benchmarks to understand what is possible and where you roughly stand, then focus on improving against your own past.
Do not turn a level into a target. When a measure becomes a target, people find ways to hit the number without improving anything. This is Goodhart's law, and DORA's own metrics guide lists "setting metrics as a goal" as its first pitfall. A team told to reach "elite deployment frequency" can split work into meaningless deployments and hit the number while delivering nothing extra.
Compare with your own past. The question that matters is whether this team, on this service, is getting better. A benchmark tells you what other teams reported; your history tells you what changed when you changed something.
Measure one application or service at a time. A team average can hide one service that fails often. See change fail rate by service.
Get a free baseline. The DORA Quick Check asks five multiple-choice questions, compares your answers with other teams and suggests which capabilities to work on.
Then work on what holds you back. Levels describe outcomes, not causes. The improving software delivery guide explains how to find the biggest constraint and work on it.
How Solidafy uses this
The Engineering Delivery app reads every team against its own past and never labels a team elite, high, medium or low.
- No published figure is suggested as a goal. The 2025 report publishes no benchmark and no performance levels, and asks each team to improve against its own past. So the one goal preset in Settings is your own baseline: "Suggest goals 10% better than now" suggests, for each measure the app has read, a target 10% better than your current value. A suggested share never goes past 100%. It is offered once the app has measured your own numbers.
- Defaults come from your own baseline too. Until you set a goal, each measure shows a default worked out the same way. A default is never a goal your team set, so it never raises an alert or reads as met or missed. Setting the app up sets no goals.
- Throughput and instability against your own trend. The Speed page reads the five metrics in DORA's two groups, against the 90 days before the period. See Throughput and instability.
- No profile is guessed. The team profile card reads the two delivery factors and names the six it cannot read. See Team profiles.
- The spread of answers is context. The guides inside the app quote the 2025 spread of answers above for each DORA metric, never as a target.
The Goals, alerts and Scout guide explains how goals and defaults work in the app.
Learn more
- Accelerate State of DevOps Report 2024, the source of the four performance levels
- State of AI-assisted Software Development 2025, the source of the spread of answers and the seven team profiles
- DORA, State of AI-assisted Software Development 2025, PDF
- DORA's software delivery performance metrics
- DORA Quick Check
- Solidafy guides: What is DORA?, The five DORA metrics, Throughput and instability, Team profiles, Improving software delivery, Well-being and burnout, Glossary