How it works

The explanation, with examples you can run.

The five metrics

Throughput: how many changes move through the system, and how fast.

Change lead time: time from a change being committed to version control to it running in production.
Deployment frequency: how many deployments happen in a period, or the time between them.
Failed deployment recovery time: how long it takes to recover from a deployment that fails and needs immediate intervention. This replaced the older, broader "time to restore service" (MTTR).

Instability: how well deployments go.

Change fail rate: the share of deployments that need immediate intervention afterwards, typically a rollback or hotfix.
Deployment rework rate: the share of deployments that are unplanned and happen because of an incident in production.

Computing them

You need two event streams: deployments (with the commits they contain) and failures linked to deployments. This sketch computes the metrics for one service over a week:

Your code

const hours = (a, b) => (new Date(b) - new Date(a)) / 36e5
const deploys = [
  { at: "2026-10-05T10:00Z", commits: ["2026-10-05T08:30Z"], failed: false, unplanned: false },
  { at: "2026-10-06T15:00Z", commits: ["2026-10-06T09:00Z", "2026-10-06T13:00Z"], failed: true, recoveredAt: "2026-10-06T15:40Z", unplanned: false },
  { at: "2026-10-06T15:35Z", commits: ["2026-10-06T15:20Z"], failed: false, unplanned: true }, // hotfix
  { at: "2026-10-08T11:00Z", commits: ["2026-10-07T16:00Z"], failed: false, unplanned: false },
  { at: "2026-10-09T09:30Z", commits: ["2026-10-09T08:00Z"], failed: false, unplanned: false },
]
const median = (xs) => { const s = [...xs].sort((a, b) => a - b); const m = s.length >> 1; return s.length % 2 ? s[m] : (s[m - 1] + s[m]) / 2 }

const leadTimes = deploys.flatMap((d) => d.commits.map((c) => hours(c, d.at)))
const failures = deploys.filter((d) => d.failed)
console.log("deployment frequency:", deploys.length, "per week")
console.log("median change lead time:", median(leadTimes).toFixed(1), "h")
console.log("change fail rate:", Math.round((failures.length / deploys.length) * 100) + "%")
console.log("failed deployment recovery time:", failures.map((d) => hours(d.at, d.recoveredAt) * 60 + " min").join(", "))
console.log("deployment rework rate:", Math.round((deploys.filter((d) => d.unplanned).length / deploys.length) * 100) + "%")

⌘/Ctrl + Enter

OutputNot run yet

Press Run to see what your code prints, in order.

Runs in this browser, in an isolated frame with no access to this page. console.log, info, warn and error are shown; code runs as a classic script, so use an async function for await.

Medians are more honest than averages here: one change that sat for a month would drag an average far away from the typical experience.

Using them well

Track all five together. Pushing deployment frequency alone can raise the fail rate; chasing a low fail rate alone tends to slow everything down. DORA's data says the best teams do well on all of them, because small changes are both quicker and safer.
Per application, over time. Different systems have different contexts. Compare a service with its own history, not with another team's.
For learning, not ranking. As soon as the numbers decide bonuses, people optimise the numbers. Use them to find the bottleneck (review waits, slow tests, manual approvals) and check whether a fix helped.
Start rough. A spreadsheet of deploys and incidents for a month already shows where time goes. DORA's Quick Check gives a baseline in a few minutes.

Check yourself

3 questions. Get them all right to finish this topic.

1.In DORA's current model, how many software delivery performance metrics are there?
2.How does DORA define change lead time?
3.A manager sets a target of 20 deployments per day for every team. What is the likely result?

0 of 3 right so far. Get all three to finish this topic.

DORA metrics: measuring delivery

How it works

The five metrics

Computing them

Using them well

Check yourself

Go deeper