Engineering Delivery

Change lead time

Note: New to DORA? Start with What is DORA?, a five minute introduction that assumes no prior knowledge.

Change lead time is how long a change takes to go from written code to running in front of customers. It is one of the five DORA metrics, also known as lead time for changes, and it usually reveals that most of that time is spent waiting rather than working.

What is change lead time?

DORA defines it as:

"The amount of time it takes for a change to go from committed to version control to deployed in production."

In plain words: the clock starts when a developer saves a piece of work into the shared code history, and it stops when that work is live for users.

A few terms in that definition:

A commit is a saved step of code changes, recorded in version control such as Git.
Being deployed in production means the change is running in the real system your customers use.

Back to our example team of six building an online booking app. A developer commits a fix for the date picker on Monday morning. It waits for a colleague to review it until Wednesday, is approved on Thursday, and goes out with the Friday release. The change lead time for that fix is four and a half days. The actual coding took a couple of hours.

Change lead time is one of DORA's three throughput metrics, alongside deployment frequency and failed deployment recovery time. The 2025 DORA report calls it "lead time for changes"; the two names mean the same thing (2025 report, p.13).

Why does it matter?

It is how long customers wait. Once a change is written, every hour it is not deployed is an hour a customer goes without the fix or feature.
It shows how fast you can react. If a security problem appears, your change lead time is roughly how quickly a normal change can respond to it.
It exposes queues. Long lead times are rarely caused by slow coding. They are caused by work sitting in queues: waiting for review, waiting for a test environment, waiting for a release window. Those queues are fixable.
Fast feedback helps people. When a developer sees their change live the same day, they still remember the details. When it ships three weeks later, they have moved on, and any problem costs more to fix.

How do you measure it?

For each change, take the time from its first commit to the moment it was deployed to production. Then take the median across all the changes deployed in a period.

Why the median and not the average? Lead times are lopsided. Most changes take a day or two, but one forgotten change that sat for three months will drag an average up and hide what usually happens. The median is the middle value: half of the changes were faster and half were slower. It tells you what a typical change experiences.

Some details to agree on:

Where the clock starts. DORA's definition starts at the commit. Some tools do not link commits to changes, so a fallback is to start when the change was opened for review, for example when a pull request was created. Say which you use.
Where the clock stops. At the production deployment that included the change, not at the merge. A merged change that waits a week for a release is still waiting.
Per application or service. As with every DORA metric, measure per application or service rather than mixing many teams together (DORA metrics guide).
Automated changes. Changes opened by bots, such as dependency updates, behave very differently from human work. Many teams leave them out so they do not skew the median.

Where the time goes

A single lead time number tells you that something is slow. Breaking it into steps tells you what. A typical change passes through four steps:

Coding: from the first commit until the change is opened for review.
Waiting for a first review: from opening the change until someone first looks at it.
In review: from the first review until the change is approved and merged.
Waiting to deploy: from the merge until the change is live in production.

For our booking app team, a typical change might look like this:

Step	Median time
Coding	6 hours
Waiting for a first review	30 hours
In review	8 hours
Waiting to deploy	40 hours

Only the coding and part of the review is someone actively working on the change. Most of the lead time is waiting. That is very common, and it is good news: waiting is easier to remove than work.

DORA's advice is to map the steps, find the constraint that holds everything else back, and act on the most important one first, rather than trying to fix everything at once (DORA value stream management guide; 2024 report, p.16). In the example, the wait to deploy is the largest step, so a team would look at their release process first. For many teams it is the wait for a first review instead; see Time to first review. The method is explained step by step in Find your biggest constraint.

Change lead time versus ticket to customer

Change lead time starts at the code. But work often starts earlier, when someone picks up a ticket and begins to think, design or ask questions. If you want to know how long a whole piece of work takes, from "we started" to "customers have it", look at Ticket to customer. The two answer different questions, and both are useful.

What does good look like?

The 2024 DORA report found four performance levels (2024 report, p.13):

Level	Change lead time	Share of respondents
Elite	Less than one day	19%
High	Between one day and one week	22%
Medium	Between one week and one month	35%
Low	Between one month and six months	25%

The 2025 report shows how all respondents answered (2025 report, p.20):

Lead time for changes	Share of respondents
Less than one hour	9.4%
Less than one day	15%
Between one day and one week	31.9%
Between one week and one month	28.3%
Between one month and six months	13.2%
More than six months	2%

Put together, 56.4% of respondents had a lead time of one week or less, and 24.4% had less than a day.

DORA reminds teams that "the best, most insightful comparisons of software delivery performance are for the same application or service over time" and that the goal is "continuous learning and improvement, not necessarily achieving top software delivery performance" (2025 report, p.20). A team that goes from three weeks to one week has done something more valuable than one that stays at two days without noticing why. See DORA performance levels for how to use these figures well.

How do you improve it?

Measure where the time goes. Break lead time into the steps above and find the longest one. Do not guess. Many teams are surprised.
Shorten the review queue. Agree as a team how quickly a change should get its first review. Google's engineering practices say "one business day is the maximum time it should take to respond to a code review request". A working agreement makes this explicit.
Keep changes small. Small changes are reviewed sooner, reviewed faster and deployed with less fear. DORA lists working in small batches as a core capability. See Change size.
Deploy as soon as a change is ready. If merged work waits for a weekly release, continuous delivery and deployment automation remove that wait.
Make tests fast and reliable. Slow or flaky tests add hours to every change. Test automation and continuous integration keep feedback quick.
Integrate often. Long-lived branches drift away from the main code and become painful to merge. Trunk-based development, where everyone merges small changes into the main branch often, keeps lead times short.
Remove approval queues. External approval boards add waiting without improving stability (DORA, streamlining change approval).
Limit work in progress. When everyone has five things on the go, every change waits for attention. See Work in progress.

Then check again at your next retrospective. DORA's improvement loop is: measure, find the constraint, commit to a change, and repeat (DORA metrics guide).

Common mistakes

Using the average. One very old change can make the average useless. Use the median.
Stopping the clock at merge. Code that is merged but not deployed has not reached anyone.
Pushing people to code faster. Coding is rarely the slow part. Pressure to type faster does not touch the queues where most of the time goes, and it hurts quality.
Treating it as a target. If lead time becomes a goal, people may skip review or split work in unhelpful ways to hit it. DORA warns against "setting metrics as a goal" (DORA metrics guide).
Reading it alone. A team can cut lead time by skipping tests, then see more failures. Read lead time next to change fail rate.

How Solidafy measures it

In the Engineering Delivery app:

Change lead time is the median, over changes merged in the period you choose, from the first commit to the production deploy. Where the code host does not link commits, it starts from when the change was opened.
Changes opened by bots, such as Dependabot, are left out.
Where the time goes shows "A typical change, step by step": the median hours a change spent coding, waiting for review, in review and waiting to deploy. The longest step is marked, and you can open any step to see the changes that spent longest in it. A step no connected tool can time is not measured, never estimated.
The default goal comes 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. You can accept the default, edit it, or set your own goal. A default is a suggestion, never a grade, and it never raises an alert on its own.
Figures are per team, read against your own recent past. No one is named.

You find change lead time on the Overview and on the Speed page, next to where the time goes; the Speed guide explains how to read and shorten it.

Learn more

From DORA:

Also: Google engineering practices, speed of code reviews

Related Solidafy guides: