Engineering Delivery

Speed

The Speed page shows how quickly a change reaches your customers once it is committed. It holds three of the five DORA metrics, deployment frequency, change lead time and failed deployment recovery time, plus a step by step view of where a typical change spends its time. If you only look at one part of the page, look at "Where the time goes": it tells you what to work on first.

New to DORA? Start with What is DORA?, then come back here.

Where to find it

Open Engineering Delivery, choose Delivery on the left, then the Speed tab. The page has these parts, top to bottom:

Speed update: one sentence on how fast changes reach customers, with a status word.
Speed measures: three tiles, one per metric. Open a tile to see the changes or releases behind it.
Throughput and instability: the five DORA metrics in DORA's two groups, against the 90 days before. See Throughput and instability.
Your team profile: what the app can read of DORA's team profiles, and what it cannot. See Team profiles.
AI-assisted work against the rest: lead time and fixes for AI-assisted changes against the rest, month by month, when you have AI-assisted changes. See AI against the rest.
Two charts: deployment frequency and change lead time, month by month.
Where the time goes: a typical change split into its steps.

Every tile has a guide under How these are measured. It says why the measure matters, how the app reads it and what good looks like, and links to the full guides on this site.

Throughout this page we follow a fictional team of six who build an online booking app.

Deployment frequency

The tile shows how often your team puts changes live, as production deploys per week over the period you chose.

What a reading means. More deploys usually means smaller deploys, and small deploys are easier to test, easier to undo and reach customers sooner. A low number is rarely about effort. It usually means deploying is manual, slow or scary, so people save changes up and release them together.

Common causes of a low or falling number:

Releases wait for a weekly window or a manual sign off.
Deploying needs a person to follow a checklist.
Tests are slow or flaky, so nobody trusts a change until a long check has run.
Big changes that take days to finish.

How to improve it, in order:

Ship smaller changes. See Change size.
Deploy automatically once checks pass, instead of batching releases.
Put unfinished work behind a feature flag, so finished code does not wait for the rest of a feature.

How it is measured. Production deploys counted under the deployment rule in Settings ("What counts as a deploy"), per week. A deploy counts whoever merged it, a bot too.

The chart under the tiles reads "Production deploys a week, by month. Higher means faster feedback." Open a month to see deploys by service: how often each service reaches production, and how many of its deploys needed a fix.

Read the full Deployment frequency guide for definitions, DORA's figures and more ways to improve.

Change lead time

The tile shows how long a typical change takes to reach customers, from its first commit to the production deploy that ships it.

What a reading means. It is how long a customer waits for a change once work on the code starts. A long lead time is almost never slow typing. It is changes waiting: for a reviewer, for a test environment, for a release.

Common causes of a long or rising lead time:

Changes wait a day or more for a first review.
Merged changes wait for a scheduled release.
Changes are large, so review takes several rounds.

How to improve it, in order:

Find the longest wait in Where the time goes, below.
Agree a review window as a team, for example a first review within one working day.
Keep changes small so review and deploy are quick.

How it is measured. The median over changes merged in the period you chose. The median is the middle value: half the changes took less, half took more, so one forgotten change cannot drag the number up. The clock starts at the first commit, or when the change was opened where the code host does not link commits. Changes opened by bots, such as Dependabot, are left out.

The chart reads "Median days from first commit to production, by month. Lower is better." Open a month to see the slowest changes to reach customers, longest first, with the part of the journey that took most time.

When two or more teams are in view, the chart has a By team switch. Turned on, it draws one line for each team, and leaves out teams too small to show on their own. Compare each line with that team's own past, not with the other lines.

Read the full Change lead time guide.

Failed deployment recovery time

The tile shows how long it takes to put things right after a release breaks. Customers live with the problem for that long.

What a reading means. Every team ships a bad change now and then. What matters is how fast you notice it and undo or repair it. A long recovery time usually means rolling back is hard, problems are noticed late, or the fix has to go through the same slow path as any other change.

How to improve it, in order:

Make rolling back one step.
Keep changes small so the cause of a problem is easy to find.
Write down what slowed the last recovery, then fix that one thing.

How it is measured. The median time from a release that needed intervention (rolled back or hotfixed) to the change that fixed it. With an incident source in Settings, the app uses the median time to restore the resolved incidents opened in the period instead, and the tile says which. The Incidents page lists those incidents by service.

Read the full Failed deployment recovery time guide.

Where the time goes

"A typical change, step by step" splits a change's journey into four steps and shows the median hours a merged change spent in each. The longest step is marked, and that is the one to work on first.

The four steps:

Step	What it covers
Coding	From the first commit until the change is opened for review.
Waiting for review	From opening the change until its first review.
In review	From the first review until the change is merged.
Waiting to deploy	From the merge until the change is live in production.

Open any step to see the changes that spent longest in it. That list is where the conversation starts: why did these wait?

For our booking team, a typical change spends 6 hours coding, 30 hours waiting for review, 8 hours in review and 40 hours waiting to deploy. Only a fraction of that is anyone working on the change. The rest is queues.

What to do when each step is the longest:

Coding is longest. The change is probably too big, or the work was unclear when it started. Split work into changes that do one thing, and make sure a ticket is ready before someone picks it up. See Change size.
Waiting for review is longest. This is the most common case and the easiest to shorten. Agree a review window, review before starting something new, and make waiting changes visible at standup. See Time to first review.
In review is longest. Changes go back and forth too many times. Smaller changes and a clear description of what each one does usually help most. See Time to merge.
Waiting to deploy is longest. Merged work sits waiting for a release. Deploy automatically once checks pass, rather than on a schedule. See Deployment frequency.

Tip: Fix one step at a time. Once the longest step shrinks, another one becomes the longest. That is progress, not failure. The Change lead time guide explains the method in more depth, and Find your biggest constraint shows how to make it a team habit.

How it is measured. The median hours a change merged in the period you chose spent in each step. A step no connected tool can time is not measured. You may see one of these notes under the chart:

"Connect your code source to time this step. Nothing is estimated." The step needs data from a tool that is not connected yet. See Setting it up.
"No change merged in the last 30 days was timed in this step." The tool is connected, but no change in the period has the timestamps this step needs.

Read Speed next to Quality

Speed is half the picture. A team can raise its deploys and cut its lead time by skipping tests and reviews, and pay for it in broken releases. DORA groups deployment frequency, change lead time and recovery time as throughput, and change fail rate and rework rate as instability, so that you always look at both. After a change to how you work, check the Quality page too. If speed went up and fixes stayed flat or fell, the change worked.

Questions the app raises

What does the status word on the Speed update mean?

The status follows change lead time against the period you compare with:

Improving: changes reach customers faster than before.
Needs attention: changes take longer to reach customers than before.
Steady: no clear change either way.
Not connected: no code source is connected, so lead time cannot be read.

When nothing reached customers in the period, there is no status word at all, only "No change reached customers in this period, so there is no lead time to show."

It says "Changes reach customers in 4 days, and the longest step is waiting for review". What do I do?

Work on that step first. Open it under Where the time goes to see the changes that waited longest, and talk them through at standup or retro. For waiting for review, the usual fix is a review window the team agrees on. The advice for every step is in Where the time goes.

It says "Connect your code to see how fast changes reach customers. Nothing is estimated."

Engineering Delivery has no code source to read changes from yet. An admin can connect GitHub, GitLab or Bitbucket from Setup. See Setting it up.

It says "No change reached customers in this period, so there is no lead time to show."

No change was merged and deployed in the period you chose. Choose a longer period, or check that the deployment rule in Settings matches how your team actually deploys.

A tile is locked. Why?

A locked tile needs data from a tool you have not connected, and the app never fills the gap with a guess. The tile says what it needs. Setting it up explains each connection.

What goal should we set?

Until you set one, each tile shows a default goal from your own baseline: 10% better than your current value, once the app has measured it. DORA's 2025 report publishes no target, so no published figure is used. Defaults are suggestions, never a grade of your team. You can accept them, edit them, or set your own in Settings. See How Solidafy uses this on the performance levels page.

Deploys went up but lead time did not move. Why?

More deploys only shorten lead time if changes were waiting to deploy. If most of the time is spent waiting for review, deploying more often helps little. Check Where the time goes to see which step holds the time.

Learn more

Official sources:

Related guides: