Deploy free

DORA metrics: reading the four keys without fooling yourself

The DORA metrics dashboard grades your delivery on the four keys — lead time for changes, deploy frequency, change failure rate, and time to restore — against Elite/High/Medium/Low tiers. Here's how to read it, and what to do when a tile turns amber.

deckgauge · Board · Intelligence
Lead time (p50)
31h
High
Deploy freq
4.2/wk
Elite
Change-fail
9%
High
Restore time
3.5h
Medium

DORA tiles with tiers.

What it measures, and where the data comes from

Four tiles, each benchmarked to a tier. Only one is measured end-to-end today; the other three are honest proxies until you wire up deploy and incident data.

  • Lead time for changes — median hours from a change's first commit to its PR merging. Pulled from GitHub, GitLab, and Azure DevOps pull/merge requests. This one is exact.
  • Deploy frequency — proxied from merge cadence. Treat it as "how often work reaches the trunk", not literal production deploys, until a deploy source is connected.
  • Change failure rate — proxied from revert- and fix-style commits. Directional.
  • Time to restore — proxied from the gap between a fix and the change it corrects. Directional.
Read the proxies as trendsDeploy frequency, change failure rate, and time to restore are inferred, not observed. Watch their direction over weeks — don't quote the absolute number in a board deck.

How to read it

Scan the tiers first, not the numbers. A wall of Elite/High is a healthy pipeline. The tile sitting a tier or two below the others is your constraint — and it's almost always a process gap, not an effort gap.

Lead time is the tile to trust most. If it's worse than the rest, the bottleneck lives between commit and merge: slow reviews, oversized batches, or a flaky pipeline. Fast coders with slow lead time is the most common pattern we see.

What it tells you over time

Give a tier at least a quarter before you trust it. A lead-time tile drifting from Elite to High to Medium over a quarter is a slow leak — usually reviews stretching out or PRs getting bigger. Catch it at High, not Low.

Example situations

1. Busy board, slow shipping

deckgauge · DORA
Lead time (p50)
6.1d
Medium
Deploy freq
5.0/wk
Elite
Change-fail
7%
High
Restore time
2.9h
High

Lead time lagging the other keys.

What you're seeing: three green tiles and one amber. Deploy frequency is Elite, so people are shipping — but lead time is Medium, so each change crawls to merge.

How to react: don't push people to "go faster." Pair this with the Review Pickup Time and PR Size widgets. If pickup is high, reviews are the jam; if PRs skew Large, batch size is.

Managerial playMake batch size the target, not review speed. Split the ticket into sub-400-line slices before anyone opens an editor — plan the work as a stack of mergeable PRs instead of carving up one giant diff under deadline pressure after the fact. Put a hard "one reviewer, one business day" expectation on the team: whoever's assigned either reviews it that day or hands it off, no PR just sits waiting. If the real jam turns out to be review latency rather than batch size, the Review Pickup Time guide has the SLA playbook for that — no need to run two versions of the same fix.

2. Change failure rate creeping up after a push

deckgauge · DORA
Lead time (p50)
22h
Elite
Deploy freq
6.4/wk
Elite
Change-fail
21%
Low
Restore time
7.2h
Medium

Change-fail proxy trending the wrong way.

What you're seeing: speed is Elite but the change-fail proxy jumped to Low right after a delivery crunch. Fast and fragile.

How to react: this is the classic "we hit the date by cutting corners" signature. Confirm it against Rework Rate and Bug Rate before acting — the proxy can spike on a burst of legitimate reverts.

Managerial playResist the urge to add a heavyweight process. Ask the team what they skipped under pressure — usually tests or a real review. Give them one slack sprint to pay it down, and stop rewarding date-hitting that ignores quality. Celebrate a boring, stable week out loud.

Frequently asked

What are the four DORA metrics?
Lead time for changes, deployment frequency, change failure rate, and time to restore service. The dashboard grades each against Elite, High, Medium and Low tiers.
Which DORA metrics does Deckgauge measure directly?
Lead time for changes is measured directly from first commit to merge. Where deployment or incident sources are not connected, deployment frequency and time to restore are derived and are labelled as proxies rather than presented as measurements.
What should I do when a DORA tile turns amber?
Read the four together rather than acting on one. They are designed to be in tension: throughput improving while change failure rate climbs is a different problem from both moving the same way, and the combination tells you which.

Related widgets

Last updated