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.

Repo-level DORA

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

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.

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.

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.