What are DORA metrics, and how should a small team track them?

Most small software teams know when delivery feels slow. Fewer can say how slow, or whether last quarter's changes helped. DORA metrics give you a short, well-tested set of numbers for exactly that question. This guide explains what they measure, what "good" looks like, and how a team of 5 to 50 people can track them without building a data pipeline.

What are DORA metrics?

DORA (DevOps Research and Assessment) is a long-running research programme, now part of Google Cloud. Its yearly State of DevOps reports found that a small set of delivery measures predicts how well software teams perform.

DORA's current guide lists five metrics in two groups (DORA, software delivery performance metrics):

Throughput

• Change lead time: how long a change takes to go from a commit to running in production.
• Deployment frequency: how often you deploy to production.
• Failed deployment recovery time: how long it takes to recover when a deployment fails and needs urgent action. This replaced the older "mean time to restore".

Instability

• Change fail rate: the share of deployments that need urgent intervention, such as a rollback or hotfix.
• Deployment rework rate: the share of deployments that are unplanned and triggered by a production incident.

The first four are the "classic" DORA metrics most tools report. Rework rate is newer.

What does good look like?

The 2024 Accelerate State of DevOps Report grouped respondents into four performance clusters (DORA 2024 report; figures as summarised by Octopus Deploy):

Two things stand out. First, elite teams were fewer than one in five organisations surveyed. Second, the medium cluster had a lower change fail rate than the high cluster. Speed and stability do usually move together, but not always. That is why you should read the four numbers together, not one at a time.

Should a small team bother?

Yes, with one caution. A team that ships eight releases a month has a small sample. One bad deployment can move change fail rate from 0% to 12.5%. So treat the numbers as a trend, not a grade.

For agencies and consultancies the metrics answer questions clients already ask:

• "How quickly can you get this fix live?" is change lead time.
• "How often do your releases break things?" is change fail rate.
• "When something breaks, how long until it is fixed?" is recovery time.

For in-house teams they give a neutral way to discuss process changes. If you move from fortnightly to weekly releases, the numbers show whether quality held.

How do you track DORA metrics without extra tooling?

You need three kinds of data, linked together:

1. Commits and pull requests, so you know when work started moving through code.
2. Deployments, with a timestamp and environment, so you know when it reached production.
3. Incidents, linked to the deployment that caused them, so you can count failures and recovery time.

The hard part is usually the links, not the data. If commits live in GitHub, deployments in a CI log and incidents in a separate support desk, someone has to stitch them together by hand each month.

Here is a worked example with fictional data. Northwind Logistics' development team deployed its customer portal 12 times in September. Two deployments caused incidents. Ticket NW-142, a broken delivery-tracking page, was raised 14 minutes after a release and fixed with a hotfix 50 minutes later.

On one month of data, Northwind looks broadly like the "high" cluster on both frequency and change fail rate. The useful question is not which band it is in. It is what caused the two failures, and whether the next three months improve.

How does Jonta report DORA metrics?

Jonta's reporting and DORA metrics feature tracks deployment frequency, lead time, change failure rate and time to restore service per project. It calculates them from data already in your workspace: tickets, GitHub activity from the GitHub and deployments integration, reported deployments, and incidents logged through incidents and uptime. Once GitHub is connected and deployments are reported, there is nothing else to set up.

Each metric shows an indicative performance band. Alongside them are burndown, velocity, time-in-stage and time-against-estimate reports. Ageing and SLA alerts flag tickets stuck in a stage and incidents approaching their response or resolution targets.

To be fair about the limits: Jonta reports the four classic metrics, not deployment rework rate. If you want deep engineering analytics across many repositories and teams, a dedicated analytics product will go further. Jonta's case is that the numbers come from the same place your team already works, so the links between ticket, commit, deployment and incident exist without extra effort.

Reporting is included on every plan. The Free plan covers up to 5 users. Pro is a flat £20 a month for up to 50 users, with 10% off for annual billing. See pricing for details.

Where should you start?

Keep it simple for the first quarter:

• Connect your repository and record every production deployment.
• Link every incident to the deployment that caused it, even when the answer is "none".
• Review the four numbers once a month, alongside the incidents behind them.
• Pick one thing to improve per quarter, such as smaller pull requests or a faster rollback.

If you want to see the metrics on your own projects, book a demo or get started and we will set up a workspace for your team.

Questions people also ask

Written by the Jonta team.