DevOps Research and Assessment (DORA) is the research program — originally led by Nicole Forsgren, Jez Humble, and Gene Kim — that spent years surveying tens of thousands of engineering teams to answer a deceptively hard question: how is DevOps delivery value measured in a way that's rigorous rather than anecdotal? The answer was four metrics that consistently separated high-performing engineering organizations from low-performing ones, published in the book Accelerate and continued today under Google's DORA research umbrella.
What are the four DORA metrics?
The four metrics fall into two pairs — throughput and stability — and DORA's central finding is that elite teams excel at both simultaneously, disproving the assumption that speed and stability trade off against each other.
- Deployment frequency — how often an organization successfully releases to production. Elite performers deploy on demand, multiple times a day; low performers deploy monthly or less.
- Lead time for changes — the time from a code commit landing to that code running in production. Elite teams measure this in hours; low performers in months.
- Change failure rate — the percentage of deployments that cause a failure in production requiring a fix (rollback, hotfix, patch). Lower is better, and elite teams consistently show single-digit percentages.
- Time to restore service — when a failure does happen, how long it takes to recover. Elite teams restore service in under an hour; low performers can take a week or more.
A fifth metric, reliability, was added in later research to capture user-facing operational performance (uptime, latency, and general operability) alongside the original four.
Why does gene kim devops research matter for security teams specifically?
Gene Kim's contribution — through The Phoenix Project, The DevOps Handbook, and the DORA research itself — was making the empirical case that speed and quality are not opposing forces when the underlying engineering practices are sound. That finding has a direct security corollary that's easy to miss: teams with high deployment frequency and low change failure rate also tend to patch known vulnerabilities faster, because the same practices that make delivery safe (small batch sizes, automated testing, fast feedback loops, trunk-based development) make it safe to ship a security fix quickly too.
The inverse is also true and shows up constantly in incident postmortems: organizations with slow, high-risk deployment processes often sit on a known CVE for months, not because nobody flagged it, but because their release process makes any change — security fix included — expensive and risky to ship. Improving DORA metrics and improving security posture are, in a real sense, the same engineering investment viewed from two angles.
How does security tooling affect DORA metrics in practice?
This is where DevSecOps tooling choices show up in the numbers, for better or worse:
- Scanning that blocks the pipeline with high false-positive rates directly hurts lead time and deployment frequency — engineers learn to route around or ignore a noisy gate, which also quietly degrades change failure rate over time.
- Scanning that's accurate and fast (running in CI in seconds rather than tying up a build for twenty minutes) can improve change failure rate without hurting throughput, because it catches real issues before they reach production rather than after.
- Slow, batch-oriented dependency updates (quarterly "upgrade sprints" instead of continuous, small version bumps) push toward the low-performer end of both lead time and deployment frequency, and tend to correlate with larger, riskier changes when updates finally do happen.
This is the core argument for integrating SCA and SAST/DAST directly into the CI pipeline rather than as a separate, slower gate: security checks that run in the same fast feedback loop as tests reinforce good DORA metrics instead of fighting them.
How do you start measuring your own DORA metrics?
Most teams can approximate the four metrics from data they already have — deploy logs, git history, and incident tickets — before investing in a dedicated platform:
- Deployment frequency and lead time can usually be pulled from CI/CD system logs (GitHub Actions, GitLab CI, Jenkins) by measuring commit-to-deploy timestamps.
- Change failure rate requires tagging deployments that led to an incident, rollback, or hotfix — a lightweight convention (a label on the relevant ticket) is often enough to start.
- Time to restore service comes from incident-management timestamps (detection to resolution).
Start with rough numbers over a few months rather than waiting for perfect instrumentation — the trend line matters more than precision at first.
FAQ
What is DevOps Research and Assessment (DORA) in one sentence?
It's the research program that identified four measurable metrics — deployment frequency, lead time for changes, change failure rate, and time to restore service — that reliably predict software delivery performance.
Is DORA the same as the EU's Digital Operational Resilience Act?
No — that's an unrelated regulation that happens to share the acronym. DevOps Research and Assessment refers specifically to the software delivery performance research.
How is DevOps delivery value measured beyond the four DORA metrics?
DORA research also tracks a fifth reliability metric and correlates delivery performance with organizational outcomes like employee burnout, profitability, and market share, but the original four remain the most widely adopted operational metrics.
Can a small team benefit from tracking DORA metrics?
Yes — the metrics scale down fine. Even a single-team startup can track deploy frequency and change failure rate from CI logs and use the trend to guide process improvements.