Key Takeaways
- DORA is four measures of delivery performance, deployment frequency, lead time for changes, change failure rate, and failed deployment recovery time, that together balance speed against stability.
- Two keys measure throughput and two measure quality, so optimizing one pair at the expense of the other is exactly what the metrics are designed to expose.
- In 2026 only about 16 percent of teams deploy on demand and fewer than 10 percent get a change to production in under an hour, so the goal is your own trend line, not an elite label.
- Jira measures the in-workflow portion well through issue timestamps and status transitions, but deployment frequency, change failure rate, and recovery time need CI/CD and incident data, so a full DORA picture combines Jira with pipeline tooling.
- Start with the flow metrics you already have: Time in Status, Cycle Time & Lead Time Reports surfaces six flow metrics on the board with no setup and a Rovo AI agent that explains bottlenecks in plain language.
DORA metrics are four measures of software delivery performance — deployment frequency, lead time for changes, change failure rate, and failed deployment recovery time — that together reveal how quickly and how safely a team ships software. Much of the foundation can be tracked inside Jira, and this guide explains what each metric means, what “good” looks like in 2026, and how to start measuring them on your own board.
The four metrics come from DORA (DevOps Research and Assessment), a multi-year research program now run by Google Cloud that has surveyed tens of thousands of engineering professionals. Their value is that they balance speed against stability: two of the metrics measure throughput, and two measure how well a team holds quality while moving fast. Optimising one pair at the expense of the other is exactly what the metrics are designed to expose.
What are the four DORA metrics?
1. Deployment frequency
How often an organisation successfully releases to production. High performers deploy on demand — multiple times a day — while teams earlier in their journey may ship weekly or monthly. Frequent, small deployments are easier to test, review, and roll back than large, infrequent ones.
2. Lead time for changes
How long it takes a code change to go from committed to running in production. Shorter lead times mean faster feedback and quicker value delivery. This is the DORA metric most often confused with cycle time — we untangle the difference in cycle time vs. lead time.
3. Change failure rate
The percentage of deployments that cause a failure in production requiring remediation — a hotfix, rollback, or patch. A lower rate signals that quality practices such as testing, review, and small batch sizes are working. For the formula, the tightened 2025 benchmark and the definition traps that quietly distort the number, see our full guide to change failure rate.
4. Failed deployment recovery time
How long it takes to restore service after a failed deployment. Previously known as mean time to recovery (MTTR), DORA renamed it to focus specifically on deployment-related failures. The faster a team recovers, the less a failure costs.
What do good DORA metrics look like in 2026?
DORA’s most recent State of DevOps research — based on a survey of nearly 5,000 professionals — gives a useful sense of the spread. Only about 16% of teams deploy on demand, while roughly a quarter deploy less than once a month. On lead time, fewer than 10% of teams get a change to production in under an hour, and about a third sit in the one-day-to-one-week range. The point of benchmarks isn’t to chase an “elite” label — it’s to see which direction your own trend line is moving.
What changed in DORA’s latest research
Three things are worth knowing if you last looked at DORA a few years ago. First, recent reports have moved away from the old Elite/High/Medium/Low ranking toward richer team profiles that account for culture and stability, not just raw speed. Second, the research now pays close attention to how AI-assisted development affects delivery — faster code generation doesn’t automatically improve delivery performance if review and testing become the new bottleneck. Third, the 2025 report evolved the four keys into five: failed deployment recovery time now sits in the throughput group alongside deployment frequency and lead time for changes, and a new instability measure — rework rate, the share of deployments that are unplanned fixes for production issues — joined change failure rate. The four keys remain the backbone; the framing around them has matured.
How do you measure DORA metrics in Jira?
Jira holds the part of the delivery story that happens before code ships: when work starts, how long it waits, and when it reaches “Done.” Issue timestamps and status transitions let you measure flow time accurately — and flow time is the foundation lead time for changes builds on.
The honest caveat: Jira alone can’t produce all four keys. Deployment frequency and change failure rate need data from your CI/CD pipeline and incident tooling; true lead time for changes spans the commit-to-production window that lives partly in Git and your deploy system. A complete DORA picture usually means Jira plus a source-control or CI integration. Start with what Jira measures well — lead time and cycle time — and layer deployment data on top.
What are your options for DORA metrics tools in Jira?
Teams typically bring DORA metrics into Jira one of three ways:
- Atlassian’s own tooling. Jira’s DevOps features and Atlassian Compass can surface deployment activity once you connect your source-control and CI/CD tools — a good fit if you are already deep in the Atlassian ecosystem and want engineering-level dashboards.
- A Marketplace app. Purpose-built apps calculate delivery metrics from Jira and pipeline data with far less setup. When you compare them, check which of the keys each app truly computes (many report only one or two), where your data is processed, and whether the output is readable by people outside engineering. Our own Time in Status, Cycle Time & Lead Time Reports takes the flow-first route today — cycle time, lead time, throughput and stability out of the box — with the four DORA keys on the roadmap.
- Build it yourself. Export deployment and incident events into a data warehouse or Grafana-style dashboards. This is the most flexible option and the most engineering time to maintain — reference implementations of the four keys are the usual starting point.
Start with the flow metrics you already have
Before wiring up a full DORA pipeline, most teams benefit from simply seeing where work waits. Our Jira app, Time in Status, Cycle Time & Lead Time Reports, surfaces six flow metrics — Time in Status, Cycle Time, Lead Time, Throughput, Work Type Distribution and System Stability — on your board with no setup, and a built-in Rovo AI agent explains the bottlenecks in plain language. DORA’s four keys are on our roadmap, and the cycle-time and lead-time foundation they build on is already here today.
FAQ
Can Jira track DORA metrics on its own? Jira measures the in-workflow portion — lead time and cycle time — very well, but deployment frequency, change failure rate and recovery time need CI/CD and incident data. Most teams combine Jira with a source-control or pipeline integration.
Is lead time for changes the same as cycle time? No. Cycle time measures active work inside your process; lead time for changes measures commit-to-production. They overlap but answer different questions — see cycle time vs. lead time.
How often should we review DORA metrics? Review the trend every sprint or month. The absolute number matters less than the direction it is moving and the variation between periods.
What is a good DORA score? There is no single composite “DORA score” — the framework is four separate measures, and DORA’s 2025 research retired the old Elite/High/Medium/Low tiers in favour of seven team archetypes that weigh delivery performance alongside human factors such as burnout and organisational friction. Read each key on its own trend instead: deployment frequency and lead time improving, change failure rate and recovery time flat or falling. A team that scores well on one pair while the other pair degrades has not improved — it has traded.
What does DORA stand for? DevOps Research and Assessment — the research program, now run by Google Cloud, that defined these four metrics from survey data covering tens of thousands of engineering professionals.
What are the 5 DORA metrics? DORA’s 2025 report expanded the four keys to five. Deployment frequency, lead time for changes and failed deployment recovery time now form the throughput group, while change failure rate and the new deployment rework rate — the share of deployments that are unplanned fixes for a production incident — together measure instability. Rework rate catches what change failure rate misses: one bad release can trigger several follow-up deploys to repair it. The original four remain the core of the framework and are still the ones most tools report today.
Does Jira have built-in DORA metrics reporting? Not out of the box. Jira’s native reports don’t calculate the four DORA keys directly — most teams add a Marketplace app or connect CI/CD and incident tooling. Time in Status, Cycle Time & Lead Time Reports already surfaces the Jira-native foundation (cycle time, lead time), with the full four-key DORA view on our roadmap.
Are DORA metrics still relevant now that teams code with AI assistants? Yes — arguably more than ever. DORA’s recent research focuses on how AI-assisted development shifts the delivery bottleneck from writing code to reviewing, testing and deploying it — exactly the stages the four keys measure. We dig into this question in Does DORA still matter in the age of AI?
Measure flow in Jira, with DORA on the way: Try Time in Status, Cycle Time & Lead Time Reports free · Learn more on divim.io
Related reading: Lead Time for Changes: How to Measure and Improve It · Cycle Time vs. Lead Time · Change Failure Rate: How to Measure It
