DORA and benchmarks
- Who can use it
- Everyone can read. Only an org admin can change targets.
- Where
- Efficiency → DORA, Industry Benchmarks, Benchmark History
- Deploys come from
- GitHub Deployments and Actions runs, GitLab deployments
- Incidents come from
- PagerDuty, incident.io, Opsgenie
The four DORA keys measure how fast and how safely you ship: deployment frequency, lead time for changes, change failure rate and time to restore. DevGlimpse calculates them from deployments and incidents linked to the pull requests behind them, so the numbers come from real events, not surveys.
The four keys
| Key | What it measures | How DevGlimpse counts it |
|---|---|---|
| Deployment frequency | How often you ship to production | Successful production deploys, counted on the day each one finished and shown per week |
| Lead time for changes | How long a change takes to reach production | A linked pull request’s first commit to the production deploy that shipped it |
| Change failure rate | How often a deploy needs fixing | Failed production deploys, plus successful ones followed by a revert or hotfix pull request within the window, divided by all finished production deploys |
| Time to restore | How quickly you recover | A failed production deploy to the next successful production deploy of the same environment. Several failures in a row count as one restore, timed from the first. |
A fix pull request is one whose title starts with Revert or hotfix, or that carries a revert or hotfix label. By default it counts when it is opened within 72 hours after the deploy.
Cancelled deploys count as neither a failure nor a restore. A failure that is not yet restored is not counted until it is. For the full definitions, see the metric glossary.
A team or group is credited with a deploy when it shipped a pull request that one of its members merged. A deploy counts once per team however many members it shipped, so team rows can add up to more than the organization total. A person has no deploy count, because a deploy names no one.
Where deploys and incidents come from
Deploys. Connect GitHub and DevGlimpse reads two things through the GitHub App’s read-only permissions: GitHub Deployments, and GitHub Actions workflow runs. This covers teams that deploy through the Deployments API and teams that deploy straight from a workflow. GitLab pipelines and deployments feed the same model when GitLab is connected. See Integrations.
What counts as production. By default, a deployment counts when its environment is named production, compared without regard to case. A workspace can also name the workflows that count. Workflow re-runs are separate attempts, so a failed attempt stays a failed deploy even when a re-run succeeds.
Linking pull requests to deploys. A merged pull request links to the first successful production deploy on its base branch that contains its merge commit. When DevGlimpse cannot establish containment, it uses the first successful production deploy of that repository and branch after the merge.
Incidents. With PagerDuty, incident.io or Opsgenie connected, repositories whose service is mapped to an incident tool use incidents for two keys:
- Time to restore is the time from an incident opening to its resolution.
- A successful deploy counts as a change failure when an incident opened within the window after it.
The decision is made for each repository. A workspace can use incident-based numbers for one service and deploy-based numbers elsewhere. The headline cards say which definition they used: incident-based, deploy-based, or incident-based for some of your repositories.
Read the DORA report
- Open Efficiency → DORA.
- Choose a team or group in the filter bar, or leave All Teams for the organization, and pick a date range.
- Read each section:
- Deploy frequency: Production deploys and Deploys per week for the window, and a weekly trend. A week with no deploy reads zero.
- Change failure rate: Change failure rate, Change failures and a weekly trend.
- By team: Deploys by team over the window, busiest first. Select a team to open its page.
- Time to restore: Mean time to restore, Restores and a weekly history.
Lead time for changes sits in PR Workflow under Lead time by stage, next to merge → deploy, the last stage from merge to the production deploy that shipped it.
Use the Time filter to measure restore time and lead time in working hours instead of calendar time.
If you connected GitHub before DevGlimpse added deployment data, GitHub asks an organization owner to approve the new Deployments and Actions permissions. Until someone approves them, DORA reads Not connected. A notice on Admin → Integrations tells you when permissions are waiting.
Industry benchmarks
Industry Benchmarks compares last week against a target for each metric. Last week is Monday to Sunday in your workspace time zone. Until you set your own target, the target is the elite band from published research.
| DORA metric | Default target |
|---|---|
| Deploy frequency | At least 1 per day (on demand) |
| Lead time for changes | At most 24 hours |
| Change failure rate | At most 5% |
| Time to restore | At most 1 hour |
The default bands come from the DORA 2024 report. Select the information icon beside a metric to see where its default comes from, with a link to the research. The same page also benchmarks PR Workflow, quality and predictability metrics.
- Open Industry Benchmarks. Pick a team or group in the filter bar to see only theirs.
- Read each row: Category, Metric, Team, Status, Target, Last week and Week / week.
- Check the Status: Pass when the value meets the target, Needs attention when it does not, Not connected when the source is absent, and No data when a connected week had nothing to measure.
The bar beside each value marks the target on the same scale. The change from the week before is green when it moved toward the target and red when it moved away.
Set your own target
Only an org admin can change targets.
- On Industry Benchmarks, find the metric and select the pencil beside its target. The label next to the target reads Default or Your target.
- Use the comparator button to switch between at most (≤) and at least (≥).
- Enter the value and select Save target.
- To go back, edit the target again and select Use the default target.
A workspace target is per metric. Changing it on one row changes it for every team.
A team or group can also have its own target that overrides the workspace target. The target in force is the team’s own, else the workspace’s, else the default.
Benchmark history
Open Benchmark History to see each metric week by week against the target that was in force that week. The target line steps when you change a target, and past weeks are never rewritten. Pick a team or group in the filter bar to see only theirs. A week with nothing to measure has no point, never a zero.
You can also get an alert when a team or group misses its benchmark target. See Alerts and digests.