Spokes.wiki Search About
Defined Term standard source ↗ source url updated Wed Aug 12 2026 00:00:00 GMT+0000 (Coordinated Universal Time)

DORA metrics (the “Four Keys”)

The delivery-performance quantification framework — the other half of the “Quantification” open question that service-level-objectives only half-answered. Where SLOs measure the reliability of the running service (is the user’s experience good enough?), DORA measures the delivery pipeline that ships changes to it (how fast and how safely do changes reach production?). From Google’s DORA research program (the State of DevOps reports / Accelerate). URL-only ingest; source = dora.dev.

The metrics — throughput vs stability

Originally four keys, now framed as five, split into two axes:

Throughput (speed):

  1. Deployment Frequency — how often you deploy to production.
  2. Change Lead Time — time from commit to running in production.

Stability (safety): 3. Change Fail Rate — share of deployments needing immediate remediation (rollback/hotfix). 4. Failed Deployment Recovery Time — time to recover from a failed deployment (replaced “MTTR / time to restore” — note the term shift; it’s specifically deployment recovery now). 5. Deployment Rework Rate (newer) — share of unplanned deployments following production incidents.

Performance is bucketed into tiers (Elite → Low) against evolving annual benchmarks — exact thresholds move year to year (not pinned here; they’re re-baselined in each State of DevOps report). The 2024 thresholds are on dora-2024-report, which also records why the five-metric split happened: change failure rate correlated with the other three but could not be combined into one factor, so DORA added a rework rate question (“how many deployments in the last six months were not planned but were performed to address a user-facing bug”) and found the two together make a reliable stability factor.

The ladder has a kink in the 2024 data. The Medium cluster’s change fail rate is 10% against the High cluster’s 20% — so the tiers are not monotone in stability, and DORA says so, attributing cluster membership to factors beyond throughput and stability. Quote the tiers as clusters that emerged from the responses, not as a ranking of safety.

The headline finding

“Speed and stability are not tradeoffs.” Top performers score well on all axes at once — high throughput and high stability — overturning the intuition that shipping faster means breaking more. This is the empirical backbone under the wiki’s gitops / aiops control-loop bets: better integration of the delivery system buys both speed and safety, not one at the other’s expense.

Held against DORA’s own 2024 numbers, that reads as a claim about the best performers rather than about interventions. dora-2024-report finds internal developer platform users 8% lower on throughput and 14% lower on stability than non-users, and the Medium cluster more stable than the High one. Speed and stability travel together at the top; it does not follow that a given piece of delivery machinery buys both.

Where it sits — complements, doesn’t duplicate, SLOs

  • service-level-objectives = is the service reliable enough for users right now? (SLI/SLO/ error-budget, user-facing).
  • DORA = is the org’s change-delivery process fast and safe? (pipeline-facing).
  • They interlock: an error budget gates whether to ship; DORA measures how well the shipping itself performs. Change Fail Rate + Recovery Time are the delivery-side echo of the reliability the SLO protects, and a blown error budget should show up as DORA stability pressure.
  • Deployment metrics make the gitops loop measurable (reconcile-from-Git → deploy frequency / lead time); the aiops reliability paradox gains a yardstick too — an ops agent that drafts and applies fixes is itself a “deployer” whose Change Fail Rate / Recovery Time can be tracked.

Caveat

Delivery-process metrics, not a reliability guarantee: gameable (deploy tiny no-op changes to pad frequency) and only meaningful as a set — the four/five move together or the picture is incomplete. Benchmark tiers are vendor-defined (Google/DORA) and re-baselined yearly.

service-level-objectives · gitops · aiops · site-reliability-engineering · platform-ops · synthesis