> Source: https://www.gitdash.info/docs/metrics-dora · GitDash v4.7.1

# DORA 4 Keys

## Repo-level DORA

The four metrics from the DORA (DevOps Research and Assessment) research programme. They measure the speed and stability of software delivery. GitDash computes repo-level DORA from real merged PRs and GitHub Releases.

| Metric | What it measures | How it is calculated | DORA levels |
| --- | --- | --- | --- |
| Deploy Frequency | How often the team ships to production | Releases (the last 30) per day over the span they cover; repositories without releases use merged pull requests (the last 60 closed) instead, and the card says it is an estimate. | Elite: ≥1/day · High: ≥1/week · Medium: ≥1/month · Low: <1/month |
| Lead Time for Changes | Time from writing code to it being in production | Median time from a pull request's first commit to merge over the merged pull requests among the last 60 closed; the first commit is read for the 20 most recently updated, the rest start at the pull request's creation. p95 is shown alongside. | Elite: <1h · High: <1d · Medium: <1wk · Low: ≥1wk |
| Change Failure Rate | How often a change needs fixing in production | Merged pull requests whose branch matches hotfix, revert, fix-prod or emergency — or whose title starts with "Revert" — as a share of merged pull requests. | Elite: ≤5% · High: ≤15% · Medium: ≤30% · Low: >30% |
| Time to Restore (MTTR) | How quickly the team recovers | Mean time from opening to merging those hotfix/revert pull requests. No failures in the window counts as High. | Elite: <1h · High: <1d · Medium: <1wk · Low: ≥1wk |

## Measured vs estimated

New in v4.2.1

The calculations above are **estimates**, and they fail quietly. A team that does not tag releases has its *merge rate* reported as its deploy rate. A team that does not name branches `hotfix` or `revert` gets a change failure rate of exactly 0% — which reads as excellence rather than as no signal.

When a repository actually uses GitHub's **Deployments API**, the same three metrics become measurable and appear in a separate **Deployments** panel on the repository overview, labelled *Measured*:

| Metric | Measured definition |
| --- | --- |
| Deploy Frequency | Successful production deployments per day. A failed rollout is not a delivery, so it does not count. |
| Change Failure Rate | Failed ÷ conclusive production deployments. Pending and in-progress deploys are excluded entirely. |
| Time to Restore (MTTR) | Hours from the first failure of a streak to the next successful deploy on that environment — when it broke, not the last symptom before the fix. |

The measured figures never silently replace the estimated ones. If a repo has no deployments, the panel says so and explains what the numbers above actually represent. Knowing which of the two you are reading matters more than the number itself.

**What actually creates a deployment record** — the most common surprise here is a repository that deploys every day through GitHub Actions and still shows nothing measured. A workflow that deploys is not the same thing as a deployment record. GitHub writes one only when:

| Trigger | What it looks like |
| --- | --- |
| A job declares an environment | A job-level `environment: production` key. This is the usual one-line fix — note that a `workflow_dispatch` input *named* `environment` does not count, since it is an input rather than a job key. |
| Something calls the API directly | A `POST /repos/{owner}/{repo}/deployments` call, or an action that wraps it. Platform integrations such as Vercel and Heroku do this automatically. |

Deploying to ECS, Kubernetes or a VM from a plain `run:` step creates no record, so those rollouts are invisible to these metrics no matter how often they happen. Adding the `environment:` key to the deploy job is normally enough to turn all three figures from estimated into measured.

If a repository has deployment history but nothing inside the 30-day window, the panel flags it **Recording stopped** rather than reporting an absence — it shows how many deployments are on record and how long ago the last one was. That gap is usually a replaced pipeline or a deploy step that lost its `environment:` key, and it is worth investigating rather than ignoring.

## Throughput & Velocity

| Metric | Definition | Why it matters |
| --- | --- | --- |
| PR Throughput | Number of PRs merged to the default branch per calendar week, shown over the last 12 weeks. | A proxy for delivery frequency. Sudden drops highlight blocked sprints, holidays, or process changes. |
| PR Size vs. Merge Velocity | Scatter plot: each dot is a merged PR. X-axis = lines changed (additions + deletions). Y-axis = hours from PR open to merge. The trend line shows the relationship. | Confirms that smaller PRs merge faster. Share this chart with teams to motivate smaller, more frequent changes. |
| Workflow Stability | Daily pass rate of CI runs on the default branch over 30 days. Plotted as a line chart with Elite (95%) and High (80%) reference lines. | A persistently failing main branch directly increases Change Failure Rate and slows down all PRs waiting for a green build. |