Documentation menu
DORA metrics
The DORA metrics are the four industry-standard measures of software delivery, from Google's DevOps Research and Assessment programme: how often you deploy, how long a change takes to reach production, how often a deployment goes wrong, and how fast you recover. Agile Analytics measures all four from your Git provider, your CI/CD pipelines, Jira and your error budgets.
Setting up
- Connect your Git provider: Connect GitHub, Connect GitLab or Connect Bitbucket Cloud.
- Select the repositories, or follow whole groups: Repositories and groups. A webhook on each repository brings in merges, deployments and CI jobs as they happen.
- Connect Jira for cycle time and lead time: Connect Jira.
- Link repositories to the services they deploy on the Error budgets page, so SLO alerts count as failed changes.
The page
The repository filter on the left picks which repositories count; the period at the top of the app sets the window. Each metric has a card with its value, a chart over time and a benchmark: Elite, High, Medium or Low performer, after the DORA State of DevOps tiers. Up to 62 days the charts show a bar per day, beyond that a bar per week.
| Metric | How Agile Analytics measures it | Elite | High | Medium | Low |
|---|---|---|---|---|---|
| Deployment frequency | Deployments to production per day: pipelines in which a job ran in a production environment. Staging and test environments do not count. A repository that names no environments counts every pipeline. | Several per day | Daily to weekly | Weekly to monthly | Monthly to twice a year |
| Lead time for changes | From merge into the main branch until the change is in production. Also shown: cycle time (from the ticket moving to In Progress until production) and lead time (from the ticket's creation until production), both needing Jira. | Under a day | A day to a week | A week to a month | A month to six months |
| Change failure rate | Production deployments that a later hotfix or revert merge request repaired, or that were followed within an hour by a fast-burn SLO alert on a service they deploy. | 0 to 15% | 15 to 30% | 30 to 46% | 46 to 60% |
| Time to restore | From the deployment that was live when a hotfix or revert was opened until the fix reached production. | Under an hour | Under a day | Under a week | A week to a month |
Each card also splits successful and failed deployments, so you can see the quality of your releases next to their pace.
CI queue time
The card below the four metrics shows how long CI jobs waited for a runner before they started: the median wait, the 90th percentile, the jobs that waited longer than the threshold, and the total wait. It is the time from a job becoming ready to run until a runner picked it up, as the provider reports it; waiting for earlier jobs does not count. The list names the repositories that waited longest and the runner types involved (provider-hosted, own group runners, own project runners). Queue time adds to lead time for changes without anyone noticing, and a sudden rise usually means a provider incident or too few runners.
Where the DORA metrics are used
- Delivery, one of the eight health areas: deployment frequency as the median per repository over 90 days, lead time rated on cycle time, change failure rate only when failures can be detected (linked SLOs or hotfixes in the last year).
- The Delivery tile on the overview, the team health ring and the weekly e-mail.
- Signals: a message when a metric moves to another performance tier.
- AI impact: the DORA metrics over time next to AI adoption.