DORA metrics¶

Foundations (delivery & reliability metrics) · prereq 01 (DevOps Foundations) — extends the CALMS "Measurement" pillar into concrete delivery metrics. · ~2 hours

Most engineers assume speed and safety are a trade-off: ship faster, break more things. Years of research on thousands of teams says the opposite — the same practices that make you faster also make you safer. This module covers the four (now five) research-backed metrics that predict software-delivery performance, and the mechanism behind that counterintuitive finding.

TL;DR — in 30 seconds:

DORA found four (now five) metrics that predict delivery performance: Deployment Frequency, Lead Time for Changes, Change Failure Rate, Time to Restore Service — plus Reliability.
The headline finding: throughput and stability are not a tradeoff — elite performers score well on both, because small, frequent changes are easier to test and easier to roll back.
This repo runs the first four as live collectors in the Health Dashboard (metrics/*.yml) — there's no reliability collector yet.

Learning objectives¶

By the end, the junior can:

Name and define the four core DORA metrics (Deployment Frequency, Lead Time for Changes, Change Failure Rate, Time to Restore Service) and classify each as a throughput or stability signal.
Explain the fifth metric, Reliability, and why it doesn't reduce to a single number the way the original four do.
State the headline DORA finding — throughput and stability are not a tradeoff — and explain the mechanism behind it.
Recognize the common DORA misuses (ranking teams, chasing one metric in isolation, treating a year's "elite" thresholds as fixed targets) and avoid them.

Do it with Claude

Pair, Do and Prove run in Claude Code, with the onboarding-tutor skill. Click a button to copy the exact prompt, then paste it into Claude Code in this repo.

1. Learn · acquire the concept¶

No external course — read this brief, then skim the linked guide.

Mental model (5 minutes):

DORA (DevOps Research and Assessment, now part of Google Cloud) spent years correlating engineering practices with organizational performance. The result is a small set of metrics that predict delivery performance rather than just describing activity — not vanity metrics.

The four keys — throughput vs stability¶

The original four keys split into two pairs: throughput (how fast you ship) and stability (how safely you ship).

flowchart TB
    K["DORA — the four keys"]
    K --> T["Throughput — how fast you ship"]
    K --> S["Stability — how safely you ship"]
    T --> DF["Deployment Frequency"]
    T --> LT["Lead Time for Changes"]
    S --> CFR["Change Failure Rate"]
    S --> MTTR["Time to Restore Service / MTTR"]

Metric	What it measures	Throughput / Stability	Elite ≈
Deployment Frequency	How often you release to production	Throughput	On-demand, multiple/day
Lead Time for Changes	Time from a commit merging to that code running in production	Throughput	Under an hour
Change Failure Rate	The % of production deploys that need a hotfix, rollback, or patch	Stability	0–15%
Time to Restore Service / MTTR	How long it takes to recover from a production failure	Stability	Under an hour

The fifth metric — Reliability¶

The fifth metric, Reliability (added 2021), is different in kind from the other four: it isn't one number. It asks whether the system meets user expectations, modeled on SRE's SLOs (availability, latency, correctness) rather than a single delivery-pipeline stat.

The headline finding — not a tradeoff¶

Throughput and stability are not a tradeoff. Across multiple years of the State of DevOps Report surveys (the research program behind DORA, published in Accelerate by Forsgren, Humble & Kim), elite performers consistently scored well on both at once — small, frequent changes are easier to test and easier to roll back, so speed and safety reinforce each other instead of competing.

Common misuses to avoid: - Ranking individuals or teams by these numbers — drives gaming and blame. - Optimizing one metric in isolation — e.g. forcing deploy frequency up can wreck change failure rate. - Treating a given year's "elite" thresholds as fixed targets instead of directional trends.

This repo does this for real: metrics/deployment-frequency.yml, metrics/lead-time-for-changes.yml, metrics/change-failure-rate.yml, and metrics/time-to-restore.yml implement the first four DORA metrics as live collectors in the Health Dashboard that runs this AI dev-team — see metrics/README.md. There is no reliability collector yet.

Go deeper: Measuring DORA in practice · The capabilities behind elite performance

Read next: DORA — The Four Keys (dora.dev, the official guide). Retain deck (beat 5): SE Onboarding::02 DORA Metrics.

Check yourself — name the four original DORA keys and say which are throughput vs stability

Throughput: Deployment Frequency, Lead Time for Changes. Stability: Change Failure Rate, Time to Restore Service. Throughput measures how fast you ship; stability measures how safely.

Check yourself — why isn't Reliability just 'a fifth item' on the same list as the other four?

Because it isn't one number the way the other four are. It's modeled on SRE's SLOs (availability, latency, correctness) — it asks whether the system meets user expectations, not a single delivery-pipeline stat you can read off a dashboard.

Done when: you can point to what each of the five metrics measures and, for the original four, its throughput or stability bucket — you'll make that active (unprompted recall) in Pair next.

2. Pair · passive → active¶

Drive the onboarding-tutor:

"Quiz me on the four DORA metrics — for each, throughput or stability, and what 'elite' looks like."
"Explain why speed and stability aren't a tradeoff for elite performers — what's the actual mechanism?"
"Give me a scenario where chasing one DORA metric in isolation backfires, and quiz me on which principle it violates."

Done when: you can name and define all five metrics unprompted, and explain the throughput/stability finding in your own words.

3. Do · produce an artifact¶

Exercise — map this repo's real DORA collectors:

Open metrics/deployment-frequency.yml, metrics/lead-time-for-changes.yml, metrics/change-failure-rate.yml, and metrics/time-to-restore.yml.
For each file, write down: which DORA metric it implements, what its source_command actually measures (the proxy, in one sentence — e.g. "PRs merged to main in the trailing 7 days" as the proxy for deploys), its current baseline threshold, and whether it's throughput or stability.
Optional (deeper): this repo has no reliability collector yet. Propose, in prose (no code needed), an internal proxy it could use — e.g. dashboard/watchdog freshness, kill-switch responsiveness — and explain why that's harder to reduce to one number than the other four.

Done when: you have a written 4-row table (metric → file → proxy → category) that correctly matches all four files.

Common gotchas

Ranking teams or individuals by a DORA number. Fix: use the metrics as a diagnostic for the system, not a scoreboard for people — ranking drives gaming and blame, which is exactly what the research warns against.
Chasing one metric in isolation. Fix: forcing Deployment Frequency up without watching Change Failure Rate can wreck stability — read the throughput and stability numbers together, always.
Treating a year's "elite" threshold as a fixed target. Fix: the bands in the official guide are directional trends from a specific survey year, not a certification bar to hit exactly.
Trusting a collector's number as ground truth. Fix: "PRs merged to main" is a proxy for "deployment," not the same thing — know what a metric actually measures before you quote it.
Assuming Reliability reduces to one number like the other four. Fix: it's an SLO-style judgment (availability, latency, correctness), not a single collector output — there isn't one yet in this repo.

Check yourself — why aren't throughput and stability a tradeoff for elite performers?

Small, frequent changes are easier to test and easier to roll back than large, infrequent ones — so the same practice that raises Deployment Frequency also lowers Change Failure Rate. Speed and safety reinforce each other instead of competing.

Check yourself — a manager ranks two teams by Deployment Frequency alone and rewards whichever ships more. What goes wrong?

It optimizes one metric in isolation and turns it into a scoreboard — teams can inflate deploy count (e.g. tiny no-op merges) while Change Failure Rate quietly gets worse. It violates the "not a tradeoff" finding by treating one number as the whole picture instead of reading throughput and stability together.

4. Prove · understanding gate¶

Mandatory. Pass bar in the Socratic gate.

The five metrics: Name all five DORA metrics. Of the original four, which two are throughput and which two are stability? What makes Reliability different in kind, not just a fifth item on the same list?
The key finding: Why are throughput and stability not a tradeoff? What's the mechanism that lets elite performers score well on both?
Misuse: A manager starts ranking two teams by Deployment Frequency alone and rewards whichever ships more. What goes wrong, and which DORA principle does that violate?
Grounding: Pick one of this repo's four DORA metrics/*.yml files. Which metric does it implement, what does its source_command actually measure, and where would that proxy mislead you?
Provenance: When you built your metric→file→proxy table, which rows did the tutor summarize for you versus you reading the source_command yourself? Take one row and show how you confirmed the proxy from the actual file — a plausible-sounding but wrong proxy (e.g. "counts deploys" when it really counts merged PRs) is exactly the trap.

Pass bar: you can defend the throughput/stability split, the "not a tradeoff" finding, name at least one concrete misuse with its mechanism, and show how you verified a proxy the tutor described rather than taking it on trust. "It's about shipping fast" without the why = back to Pair.

5. Retain · fight forgetting¶

Study the module deck SE Onboarding::02 DORA Metrics — its theme subdecks let you drill one area at a time:

1 The five metrics · 2 Why they matter

The deck syncs to your Anki automatically on pull (anki-sync). Done when you can recall, from the deck: all five metrics and their throughput/stability split, the "not a tradeoff" finding, and the common pitfalls.

Key takeaways¶

The four original keys split into two pairs. Deployment Frequency and Lead Time for Changes measure throughput (how fast you ship); Change Failure Rate and Time to Restore Service measure stability (how safely you ship).
Reliability, the fifth metric, is different in kind. It isn't one number — it's an SLO-style judgment (availability, latency, correctness) about whether the system meets user expectations, not a single delivery-pipeline stat.
Throughput and stability aren't a tradeoff for elite performers. Small, frequent changes are easier to test and easier to roll back, so the same practice that raises Deployment Frequency also lowers Change Failure Rate.
Ranking teams or chasing one metric in isolation breaks the model. Ranking drives gaming and blame; forcing Deployment Frequency up without watching Change Failure Rate can wreck stability — read throughput and stability together, always.
A given year's "elite" threshold is a directional trend, not a fixed target. The bands in the official guide come from a specific survey year, not a certification bar to hit exactly.
This repo's metrics/*.yml collectors are proxies, not ground truth. "PRs merged to main" stands in for "deployment" — know what a collector actually measures before you quote its number; there's no reliability collector yet.

Go deeper — curated resources¶

Hand-picked external material to take this topic further — the best books, courses, talks, and writing. Cost is tagged Free, Free online (full text/course free on the web), or Paid.

Docs · DORA — Google / DORA research team. The research program and the four keys, straight from the source. Free.
Book · Accelerate — Forsgren, Humble & Kim (IT Revolution). The book that established the four metrics. Paid.
Report · State of DevOps Report — DORA. The annual findings behind the metrics. Free.
Blog · Four Keys (Google Cloud) — Google Cloud. How to measure the four keys yourself. Free.

Gate log (mentor fills on pass)¶

Date passed:
Passed by: / checked by:
Weak spots noticed (feeds system improvement):