Trace DORA Metrics Back to the Released Build

Since 2024, DORA has assessed software delivery performance with five metrics. Change lead time, deployment frequency, and failed deployment recovery time describe throughput; change fail rate and deployment rework rate describe instability. A DORA retrospective published in January 2026 explains how that set evolved.

The metric names, however, do not by themselves define a local measurement method. A team still has to decide what counts as a deployment when measuring deployment frequency. Failed deployment recovery time needs a defined start and end.

If those operating definitions change, the time series may move even when production performance does not. DORA recommends reading the metrics together, in the context of an application or service, and as change over time. Its guidance specifically warns against misleading comparisons among unlike applications. This distinction matters when older dashboards still use MTTR. In 2023, DORA narrowed the recovery metric to failed production changes. An unrelated data center outage therefore does not automatically fall within failed deployment recovery time. When continuing an older time series, teams need to identify whether it previously counted all incidents or only disruptions caused by deployments.

Change fail rate and deployment rework rate also answer different questions. The former describes the share of deployments that require immediate intervention. The latter captures unplanned deployments resulting from a production incident. Combining them loses the distinction between the change that caused the failure and the additional deployment work it generated.

Release Provenance

The measurement also needs to point to a specific release. A commit or reused version label is not enough.

Dependencies, the build environment, configuration, migrations, and the resulting artifact can all shape what runs in production. NIST SP 800-218 recommends making release integrity verifiable and protecting the release files, provenance records, and related integrity information. That evidence can show whether two environments received the same build. A release name also needs a rollout window. During a staged deployment, more than one build may be active in the same reporting period. As a local measurement rule, the team should record when each population is attributed to the new build and which comparison window applies. Otherwise, a change may be attributed to the release even though the observed population still contained multiple versions.

Canary Signals and Business Effects

Canarying compares a limited deployment with a control population. The Google SRE Workbook calls for comparable signals that can be evaluated separately and for a defined view of acceptable behavior. Teams should turn that view into go, stop, or rollback criteria before the rollout begins. A rule written only after the charts are visible would be difficult to defend. The size of the canary population and the observation period determine which failures may become visible. A few successful requests reveal little about rarely used paths or queues that build up gradually. Time of day and load distribution also need to support a meaningful comparison. If the canary and control populations share a failure source, a common disruption may conceal a difference between releases. The analysis should account for these limits; a quiet canary does not establish how every later production scenario will behave.

Technical signals also do not automatically establish the business outcome. An HTTP-level success can coexist with incomplete order processing, and rolling back code does not undo a message that has already been sent or a migration that has already run. For releases with effects outside the artifact, the team should identify the business signal it will watch and which effects are technically reversible.

A concise release record can preserve the connection: a clearly identified release, the configuration used, the measurement definition, and the stop conditions selected for that rollout. This is not another DORA metric. It is a local bridge among the time series, release provenance, and the build users actually received.

Note: This assessment is not a substitute for a review of the specific case.