DORA metrics, defined

The four metrics, precisely defined

Each metric has a specific published definition, and most measurement arguments trace back to quietly substituting a looser one. The definitions below follow the DORA research program's usage; recent reports refer to time to restore as failed deployment recovery time, but the underlying measure is the same.

What the four keys do and do not tell you

Read together, the four keys describe the health of a delivery system: throughput (how often and how fast changes reach production) balanced against stability (how often those changes break things and how quickly service recovers). The research program's central finding is that these are not a trade-off — teams that deploy more often also tend to break less — which is why the four are read as one panel rather than cherry-picked.

They are team- and system-level indicators, not individual ones. Lead time says nothing about which engineer is slow; change failure rate says nothing about who wrote the failing change. Used for individual performance review, the metrics stop measuring the system and start measuring people's ability to game them — the standard Goodhart's-law failure. They are also trailing indicators: they tell you the delivery system degraded, not why.

Honest-measurement pitfalls

DORA metrics are easy to compute badly and hard to compute honestly. The most common corruptions are worth naming, because each one moves the numbers in a flattering direction:

• Bot and CI noise: dependency-update bots, release automation, and CI service accounts open and merge changes at machine speed. Counted naively, they inflate deployment frequency and collapse apparent lead time. Honest measurement decides explicitly which actors count — and discloses the decision.
• Fabricated baselines: when instrumentation cannot see real production deploys, some pipelines estimate them from merge events or fill gaps with assumed values. A metric resting on an estimated baseline cannot detect the regressions it exists to catch.
• Definitional drift: whether a config push, a batch release, or a per-service rollout counts as one deployment — and whether a failure means an incident ticket, a rollback, or an alert — must be pinned down before numbers are comparable across teams or over time.
• Partial visibility reported as total: measuring only the repositories and pipelines that were easy to instrument, then presenting the result as organization-wide.

How to evaluate a DORA measurement tool

Whether the four keys come from a spreadsheet, a home-grown script, or a commercial platform, the same honesty tests apply. A sound implementation reads its signal directly from the source-control and delivery systems that actually record deploys and incidents, rather than inferring activity from proxies. Where the underlying signal is not observable — no visible deploy events, no incident linkage — it should mark the affected measure as not measured rather than estimating it, because a delivery number built on assumed deploys reproduces exactly the fabricated-baseline failure described above.

Three questions separate an honest tool from a flattering one: which actors and events each metric counts, and whether that rule is disclosed; how the tool behaves when a system is not instrumented, since a blank is honest where a confident zero or a silent estimate is not; and whether definitions stay fixed over time, so a moving trend reflects the delivery system rather than a quietly changed measure.

Frequently asked questions