DORA Metrics: The Five Numbers and How to Track Them Simply

DORA metrics are the measures of software delivery performance defined by DORA, a research program run by Google Cloud. As of September 30, 2026, DORA uses five: change lead time, deployment frequency and failed deployment recovery time, which show throughput, and change fail rate and deployment rework rate, which show instability. The original “four keys” became five in 2024, when deployment rework rate was added. You can track all five for one application with a seven-column deploy log, a spreadsheet and half an hour a month. No platform is required to start.

The five DORA metrics, as DORA defines them

These are the definitions from DORA’s guide to software delivery performance metrics↗ (opens in a new tab), quoted exactly:

• Change lead time: “The amount of time it takes for a change to go from committed to version control to deployed in production.”
• Deployment frequency: “The number of deployments over a given period or the time between deployments.”
• Failed deployment recovery time: “The time it takes to recover from a deployment that fails and requires immediate intervention.”
• Change fail rate: “The ratio of deployments that require immediate intervention following a deployment.” DORA adds that this likely means a rollback or a hotfix.
• Deployment rework rate: “The ratio of deployments that are unplanned but happen as a result of an incident in production.”

DORA groups the first three as throughput, how many changes move through the system, and the last two as instability, how well deployments go. Many older articles list recovery time with the stability measures; DORA’s current guide puts it under throughput. The guide also says the metrics are best applied to one application or service at a time, and that its research keeps finding speed and stability are not trade-offs: top performers do well on all five.

From four keys to five: what changed

DORA’s own history of its delivery metrics↗ (opens in a new tab) explains the changes, and they matter if you are reading older material:

• 2023: “mean time to recover” (MTTR), also called time to restore service, was renamed and redefined as failed deployment recovery time. The new metric counts only recovery from a failure caused by a change to production, not outages from outside causes such as a data center failure.
• 2024: deployment rework rate was added as a fifth metric, because change fail rate had been acting as a stand-in for how much rework a team does.
• Reliability, which DORA’s 2021 report called a fifth metric, is described in that history as a measure of operational performance rather than software delivery.

Two wording differences to be aware of. DORA’s history page describes rework rate more loosely than the guide, as the percentage of deployments that are “unplanned work to fix bugs”; this page uses the guide’s definition, tied to production incidents. And other vendors still use the old term: Microsoft’s What is DevOps↗ (opens in a new tab) guide, for example, still talks about improving mean time to recovery. If a dashboard says MTTR, check which definition it computes.

One naming trap: DORA’s change lead time starts at the commit, not at the request. The Kanban-style lead time and cycle time that start from a task are a different pair of measures, covered in cycle time vs lead time.

How to track DORA metrics without a platform

1. Pick one application or service. Mixing a mobile app and an API in one set of numbers hides both.
2. Write down four definitions before you count anything: what counts as a deployment (does a rollback count?), what counts as a failed deployment, when a failure is recovered, and which commit time you use for a change. Keep them next to the log.
3. Keep a deploy log, one row per production deployment, filled from your CI/CD tool’s run history and from git.
4. Once a month, work out the five numbers, compare them with last month, and pick one thing to improve.

deploy,committed,deployed,failed,recovered_after,unplanned,note
D1,2026-08-31 15:00,2026-09-01 11:00,no,,no,
D2,2026-09-02 10:00,2026-09-03 14:00,no,,no,
D3,2026-09-04 11:00,2026-09-08 10:00,yes,45m,no,rolled back
D4,2026-09-08 13:00,2026-09-08 15:00,no,,yes,fix for D3

For the committed column, a team shipping one pull request per deploy can use the pull request’s last commit; a deploy that ships several changes gets one row per change, or the oldest commit if you accept a pessimistic number. Git gives the commit time directly:

# committer date of a commit, in ISO 8601
git log -1 --format=%cI <commit-sha>

A worked example: one month of deploys

A four-person team deploys its web app from Tuesday, September 1 to Friday, September 25, 2026. Each deploy ships one pull request, and lead times are in hours.

deploy  committed         deployed          lead  failed  recovered  unplanned
D1      Mon Aug 31 15:00  Tue Sep 1 11:00     20
D2      Wed Sep 2 10:00   Thu Sep 3 14:00     28
D3      Fri Sep 4 11:00   Tue Sep 8 10:00     95  yes     45 min
D4      Tue Sep 8 13:00   Tue Sep 8 15:00      2                     yes
D5      Wed Sep 9 16:00   Thu Sep 10 16:00    24
D6      Fri Sep 11 09:00  Mon Sep 14 11:00    74
D7      Tue Sep 15 14:00  Wed Sep 16 10:00    20  yes     3 h
D8      Wed Sep 16 12:00  Wed Sep 16 13:00     1                     yes
D9      Thu Sep 17 10:00  Fri Sep 18 15:00    29
D10     Fri Sep 18 16:00  Tue Sep 22 11:00    91
D11     Wed Sep 23 09:00  Thu Sep 24 10:00    25
D12     Thu Sep 24 15:00  Fri Sep 25 11:00    20

• Deployment frequency: 12 deployments in four weeks, three a week, on 10 different days.
• Change lead time: sorted, 1, 2, 20, 20, 20, 24, 25, 28, 29, 74, 91, 95. The median is 24.5 hours; the average, 35.75, is pulled up by three changes.
• Change fail rate: D3 was rolled back and D7 needed a hotfix, so 2 of 12, about 17%.
• Failed deployment recovery time: 45 minutes for D3, 3 hours for D7. With two failures, list them rather than average them.
• Deployment rework rate: D4 re-shipped the fix for D3’s problem and D8 was D7’s hotfix, both unplanned and caused by a production incident: 2 of 12, about 17%.

The useful finding is in the lead times. The three long ones, D3, D6 and D10, were all committed on a Friday, and D3 also waited out Labor Day. The team’s code is not slow; its merges wait for Monday. That points at one improvement to try next month, such as deploying merged work before the end of each day, and it would stay hidden behind a single average.

In this log the rollback of D3 is not counted as a deployment. Counting it would raise the deployment count and lower the fail rate. Either choice is defensible; changing it halfway through the year is not.

Pitfalls DORA warns about, and a few more

DORA’s guide lists its own pitfalls. In short: making a metric a goal invites gaming it; relying on one metric; using your industry as a reason not to improve; comparing very different applications; giving each team only its own slice of the metrics; turning the numbers into a competition; and spending so long on data collection that nothing improves. From running the numbers by hand, add:

• Never use DORA metrics to rate individuals. They describe a delivery system, and a person can only improve them by changing that system.
• Report medians, and look at the slow cases by name. Averages hide exactly the pattern in the example above.
• Treat a month of a small team’s data as rough. Two failures make a rate that swings wildly from month to month.
• Keep definitions fixed and dated. A new definition of failure looks exactly like an improvement.

For a first baseline before you have a log, DORA’s Quick Check↗ (opens in a new tab) asks five multiple-choice questions, compares the answers with its research, and suggests capabilities to work on; DORA says it does not store the answers.

DORA’s guide names reducing the batch size of changes as a common way to improve all five, and its page on working in small batches↗ (opens in a new tab) says the capability has become even more critical with generative AI, because AI adoption often increases delivery instability.

Where fenbs fits

fenbs does not record deployments or calculate DORA metrics, and its History shows how long ago things happened rather than exact timestamps, so the deploy log’s times come from your CI/CD tool and git. What a board does well is the follow-up. File each failed deployment as a bug, with priority 1 if it is urgent, link it to the task that shipped the change, and put what was checked in its test status and test notes. Rework then shows up as linked bugs you can read, not just a percentage. If the team decides that every failed deployment gets a bug task, record it as a rule on the Decisions and rules page; every connected AI assistant reads the rules first and follows them.