The DORA four keys (deployment frequency, lead time for changes, change failure rate and time to restore service) measure software delivery performance. They are most useful when computed from real events and decomposed by service and team, and most misleading when averaged across an org or filled in by hand.
DORA metrics are four measures of software delivery performance from the DevOps Research and Assessment research programme: deployment frequency, lead time for changes, change failure rate and time to restore service. The first two describe throughput, how fast changes reach production. The last two describe stability, how often changes fail and how quickly service recovers.
How often a service is deployed to production. Count successful production deployments per service per period, from deploy events rather than release notes written afterwards.
How long a change takes to reach production. Pick one start point (the first commit, or the pull request opening) and one end point (running in production) and keep to them, because the number is only comparable against itself. It is often dominated by review and approval queues, not by build time.
The share of production deployments that cause a failure needing remediation: a hotfix, a rollback or a patch. Divide failed deployments by total deployments over the same period. How "failed" is decided is where most of the error comes from; the change failure rate guide goes through it.
How long a service stays degraded after a failure, from the start of the incident to service restored. It is measured on incidents, and it is a different number from the time it takes to find the likely cause. Recent DORA reports have refined the name of this key (to failed deployment recovery time), so you may see either.
An org-wide average hides the thing you need: one team deploying twelve times a day averages away another shipping monthly and breaking production. And a change failure rate computed from a checkbox somebody ticks after the incident review measures diligence, not failure.
DORA's own guidance is to use the keys to improve a team against its own past, not to rank people or teams against each other. Used as a league table they get gamed, and the engineering gets worse. Compare a service with itself over time, and read the four together: a team that ships faster while its failure rate climbs has not improved.
ArcRelease derives all four keys from real deployment and incident events, decomposes them by service and by team, and shows the linkage coverage behind each number, so you know whether a metric rests on 95 percent of your releases or half of them.
Deployment frequency, lead time for changes, change failure rate and time to restore service. Two measure speed (frequency and lead time) and two measure stability (failure rate and time to restore).
DORA is the DevOps Research and Assessment research programme, which publishes the annual Accelerate State of DevOps research and is now part of Google Cloud. The four keys come from that research into what separates high-performing software teams.
Failed deployments divided by total deployments over the same period, as a percentage. A deployment counts as failed if it needed remediation such as a hotfix or a rollback.
There is no single number. DORA groups teams into performance bands, and the thresholds change between yearly reports, so check the current report for benchmarks. For your own use, compare each service with itself over time and read frequency alongside change failure rate.
Mostly yes: both describe how long it takes to recover from a failure. Be careful with the letters, since MTTR is also used for mean time to repair, resolve and recover, which are not always the same interval. State which start and end points you use.
They should not be. They describe a team's own delivery system, and the teams differ in architecture, risk and context. Used as targets or rankings they tend to be gamed. Use them to see whether a service is getting better or worse.
From the deployment and incident events it already reads from your tools, by service and by team, with the linkage coverage behind each number shown. Nobody fills in a form to produce them.
Tell us about your release process. Connect your stack in ten minutes, run a Gaja preflight on a real release, and see the reasons behind the verdict.
Free plan · ten minute setup · we reply in one to two business days