DORA metrics

DORA now publishes five software delivery metrics — deployment frequency, change lead time, change fail rate, failed deployment recovery time, and deployment rework rate (dora.dev, as of 2026-07-28). Four of them are the long-standing "four keys"; the fifth, deployment rework rate, was added in 2024. Published by DORA (DevOps Research and Assessment), they are used together to describe how fast a team ships and how well its releases hold up.

The five metrics

• Deployment frequency — how often the team deploys to production, expressed as deployments over a period or as the time between deployments.
• Change lead time — how long a change takes to go from committed in version control to running in production.
• Change fail rate (widely written "change failure rate") — the share of deployments that need immediate intervention, such as a rollback or hotfix. See change failure rate.
• Failed deployment recovery time — how long it takes to recover once a deployment fails and requires that intervention.
• Deployment rework rate — the share of deployments that are unplanned remediation of an earlier deployment rather than intended work.

The naming has moved. DORA's current software delivery performance metrics guide groups the five under throughput and instability, and the old MTTR label has been replaced by failed deployment recovery time (DORA's own term is change fail rate; "change failure rate" is the common industry spelling) — as of 2026-07-28. Content that still says "mean time to restore", or counts four keys, is quoting an earlier edition.

What CI data alone can measure

This is where most DORA dashboards overreach. A pipeline observability tool sees runs, jobs, steps, durations and outcomes — not production. Honestly scoped:

Deployment frequency is countable when every release goes out through a deploy workflow the tool can recognize; it is invisible when releases happen from a laptop, a PaaS console, or a GitOps controller reconciling outside CI. Change lead time needs the commit-to-production span, which pipeline metadata does not carry. Change failure rate and recovery time have CI-side stand-ins — default-branch failure rate over decisive runs and MTTR in CI — but a deploy that passed CI and broke production an hour later never appears in either.

Filling the production-side gaps requires deployment and incident data: a deployment tracker, an incident tool, or a change management system. Any product that claims the full set from CI data alone is either reading those systems too or relabeling something else.

Why it matters

The set is balanced on purpose. Throughput measures alone reward shipping more; stability measures alone reward shipping less. Watched together they catch the trade-off — which is also why a partial implementation misleads. A team optimizing the two metrics its tooling happens to expose usually finds the others quietly degrading.

DORA figures are self-reported survey data, so cross-company comparison is weak evidence. Your own trend is the useful signal.

TrimCI reports the CI-visible half — a DORA-lite branch health section in its PDF reports, labeled as a proxy rather than presented as the real thing. Getting the pipeline side accurate first is covered in CI pipeline failure analysis.