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.

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. 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.