DORA metrics explained in plain words

The four metrics at a glance

• Deployment frequency: how often new code reaches production.
• Lead time for changes: how long a change takes from its first commit to production.
• Change failure rate: the share of deploys that fail in production.
• Time to restore: after a failed deploy, how long until production works again.

Deployment frequency

Deployment frequency counts how often new code reaches production. More small deploys usually means each one is easier to check and easier to undo. A team that deploys once a month tends to ship big batches, and a big batch is harder to review and harder to roll back.

How to measure deployment frequency on GitHub

First decide what a production deploy is in your project. GitHub can record it in several places:

• Deployments: a deployment to an environment named production, if your pipeline creates GitHub deployments.
• Workflow runs: a run of the GitHub Actions workflow that deploys, on the branch you release from.
• Releases: a published release, if every release goes live.
• Tags: a version tag, if you tag what you ship.
• Merged pull requests: a merge into the main branch, if every merge deploys on its own.

Then count them per day, week, or month. Leave out staging, test, and preview deploys: they are not production.

In DeepGraph this number is Deploys. DeepGraph makes a first guess at production: it skips names that read as staging, test, or preview, and prefers deployments and deploy workflows, then releases, then tags, and with none of these it counts pull requests merged into the main branch. On your own project you can change the guess with one click on a chip.

Lead time for changes

Lead time for changes is how long a change takes from its first commit until it runs in production. It includes coding, review, waiting, testing, and the deploy itself. A long lead time means finished work waits before anyone can use it.

How to measure lead time on GitHub

For each merged pull request, take the time of its first commit (or the time it was opened) and the time of the first production deploy after the merge. The difference is that change's lead time. Over a week or a month, use the middle value (the median) instead of the average: one pull request that sat open for months should not hide that most changes ship in a day.

In DeepGraph this is Lead time, and it shows the middle value: half of the changes got there faster. When merges are what counts as production, lead time ends at the merge.

Change failure rate

Change failure rate is the share of deploys that fail in production and need a fix. A rising rate means changes reach people before they are ready.

How to measure change failure rate on GitHub

Count the production deploys that failed and divide by all production deploys. You need a place that records failures: a GitHub deployment whose status is failure or error, or a deploy workflow run that failed or timed out. Releases, tags, and merged pull requests only say that something shipped, so they cannot tell you what failed.

In DeepGraph this is Failed deploys. A failed deploy that is retried until it works counts once.

Time to restore

Time to restore is how long it takes to get production working again after a failed deploy. Short times usually mean small changes, good alerts, and an easy way to roll back.

How to measure time to restore on GitHub

For each failed production deploy, measure the time until the next good deploy to the same place, such as the same environment or the same workflow. Again, use the middle value.

In DeepGraph this is Time to restore: the time until the next good deploy, as the middle value.

A short example

Say a team deployed 20 times in a month. Two of those deploys failed, and each was fixed by a new deploy within an hour. The team's numbers for that month:

• Deploys: 20
• Failed deploys: 10% (2 of 20)
• Time to restore: under an hour

If most changes went from first commit to production within two days, the lead time is under two days. None of these numbers says the team is good or bad on its own. Together they show where work waits and where it breaks.

How to read them

• Read speed and safety together. Deploying more often is only good if failures don't rise with it.
• Compare a team with itself over time, not with another team that ships a different product.
• Look behind the number. A long lead time may be slow reviews, a release freeze, or one big change.
• Don't use them to rank people. They describe how work flows through a team, not how good someone's work is.
• Check the yearly research. DORA publishes its reports and benchmarks at dora.dev. Use them to see what is possible, not as a target for one team.

DORA and SPACE

SPACE is another research framework for looking at developer work. It covers five areas: satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. DORA is narrower: it measures how changes flow from commit to production. Many teams use the four DORA numbers for delivery and ask their people directly about the rest, since no Git history can tell you how satisfied someone is.

Where the data comes from

You don't need a new tool on every project to get started. Most of the data already sits in your code host: merged pull requests, deployments, workflow runs, releases, and tags. The tricky part is deciding which of them count as production. A staging deploy is not a production deploy.

See DORA for your GitHub projects

DeepGraph reads these four numbers from your GitHub projects through the DeepGraph GitHub App. It guesses which deployments, workflows, releases, or tags are production, and on your own projects you can change the guess with one click on a chip. You see the numbers for a project, a folder, a person, or a team, next to the commits behind them, and you can put people and teams on one chart or group them into teams.

Read DORA for GitHub projects, see the DORA questions in the FAQ, or start with the Getting started guide.