DORA Metrics Explained: How to Measure DevOps Performance
Basics4 minInnovialabs editorial team
In short
DORA metrics measure delivery with four numbers: how often you deploy, how fast a commit reaches production, how often changes break production and how quickly you recover; together they show both speed and stability.
The short answer
DORA metrics come from the DevOps Research and Assessment program and describe how well a team delivers software. There are four of them:
- Deployment frequency — how often you release to production.
- Lead time for changes — how long it takes for a commit to reach production.
- Change failure rate — what share of deployments cause a failure that needs a fix, rollback or hotfix.
- Time to restore service (also called failed deployment recovery time) — how long it takes to recover after such a failure.
The first two measure speed, the last two measure stability. The key idea: good teams improve both at once, they do not trade one for the other.
What each metric shows
| Metric | Question it answers | What usually improves it |
|---|---|---|
| Deployment frequency | Can we ship small changes often? | Small pull requests, automated pipeline, feature flags |
| Lead time for changes | How long does a ready change wait? | Faster reviews, fast tests, no manual approval queues |
| Change failure rate | How often do releases hurt users? | Tests, code review, gradual rollouts, monitoring |
| Time to restore | How quickly do we fix production? | Easy rollback, alerts, runbooks, observability |
How to collect them from Git and CI
You do not need a special platform to start. Most data already exists in your tools.
Deployment frequency
- Count successful runs of the production deploy job in CI (GitHub Actions, GitLab CI and similar).
- Alternatively, count release tags or deployments recorded via the deployments API of your Git hosting.
Lead time for changes
- For each deployment, take the commits it contains.
- Lead time = deploy time minus commit time (or minus the time the pull request was opened, if you prefer).
- Use the median, not the average: a few old commits will distort the mean.
Change failure rate
- Decide what counts as a failure: a rollback, a hotfix, an incident linked to a release.
- Mark them consistently: a label on the incident, a
hotfixbranch prefix, a revert commit. - Rate = failed deployments divided by all deployments for the period.
Time to restore
- Take incidents from your incident tracker or alerting system.
- Time = resolution time minus start time (or detection time, if start time is unknown).
A simple way to get commit-to-tag times for a release:
git log --format='%H %cI' v1.4.0..v1.5.0
Compare each commit time with the time the v1.5.0 deployment finished, and take the median across releases.
Getting started
- Agree on definitions first: what is "production", what is a "failure", when does an incident start.
- Collect data for a few weeks before drawing conclusions.
- Look at trends for your own team, not at comparisons with other companies.
- Pick one bottleneck at a time. If lead time is long because reviews wait for days, work on reviews, not on the pipeline.
- Review the numbers together with the team, as input for retrospectives.
Do not game the metrics
Once a metric becomes a target, people start optimizing the number instead of the result. Typical ways DORA gets gamed:
- Splitting one change into many trivial deploys to raise deployment frequency.
- Not recording rollbacks or hotfixes as failures to keep the failure rate low.
- Closing incidents early to make recovery time look better.
- Comparing teams with different products and penalizing the "slower" one.
How to avoid it:
- Never use DORA metrics for individual performance reviews.
- Always look at all four together: speed without stability is a warning sign.
- Combine numbers with qualitative signals: developer feedback, customer complaints, incident reviews.
- Automate collection so that nobody enters numbers by hand.