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.
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
Two 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. 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.
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 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.
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.
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
2 Comments
Leave your reply.