DORA metrics

Deployment frequency, lead time for changes, change failure rate and time to restore — what each one counts here.

Insights → DORA metrics

DORA metrics are four industry-standard measures of software delivery: how often you ship, how fast a change gets through, how often a release causes problems, and how quickly problems are fixed. They appear on the Insights page, worked out from your releases, bugs and linked pull requests.

Where to find them

Open Insights from the sidebar.
Choose a project (or All projects) and a date window at the top.
Scroll to DORA metrics, below the charts.

Each metric shows its value, a line explaining what it was based on, and a rating — Elite, High, Medium or Low — once there is data to rate.

Deployment frequency

Releases shipped per week in the window. A release counts on the day it was marked shipped (press Ship on it in Releases). The Deployments chart beside it shows shipped releases per day.

Elite: 7 or more a week
High: at least 1 a week
Medium: at least roughly 1 a month (0.23 a week)
Low: less often

Lead time for changes

The median time from a pull request being opened to it being merged, across pull requests merged in the window. It measures open-to-merge, not commit-to-production.

Elite: a day or less
High: a week or less
Medium: 30 days or less
Low: longer

Change failure rate

The share of releases shipped in the window that were followed by a new Bug issue within 7 days. It is an approximation of "this release caused rework", not a record of rollbacks or incidents.

Elite: 15% or less
High: 30% or less
Medium: 45% or less
Low: more

Mean time to restore

The median time Bug issues took from being created to being done, across bugs created in the window that are now done. It stands in for time to restore service, since bugs are the closest record of a fault the app keeps.

Elite: an hour or less
High: a day or less
Medium: a week or less
Low: longer

Where the data comes from

Releases feed deployment frequency and change failure rate.
Bug issues (issues of the Bug type) feed change failure rate and time to restore. Only bugs created inside the window are considered.
Pull requests feed lead time, the Bug-fix PR ratio (the share of merged pull requests linked to a bug) and Code review. Available on plans that include GitHub Integration. Pull and merge requests from GitHub, GitLab and Bitbucket count once the repository is connected and mapped to a project, and only when the request names an issue key in its title, description or branch name.

Time to first review and reviewer load need review events from your provider. On GitHub, enable the GitHub App's "Pull request reviews" webhook event; without it pull requests still sync but review timing does not.

When there is no data

A metric with nothing to measure shows a dash and no rating, with the reason underneath:

Deployment frequency: 0 releases in range. Change failure rate: No releases in range.
Lead time: No merged PRs in range, or Connect GitHub to track this where the integration is not on your plan.
Time to restore: No resolved bugs in range.

Widen the window or choose another project to find data. The four values are also in the CSV from Insights' Export button.