Lead Time for Changes

CI/CD hub

One of the four DORA metrics — measures the time from a code commit to that code running in production. Elite performers achieve lead times under one hour. Long lead times indicate slow pipelines, large batch sizes, or excessive manual gates.

Lead Time for Changes

Lead Time for Changes is one of the four DORA metrics. It measures the elapsed time from a code commit to that same code running successfully in production. It is a speed metric that captures the entire path a change takes — code review, pipeline execution, and any approval gates — not just how fast the pipeline itself runs.

What Contributes to Lead Time

◈ DIAGRAM

+------------------------------------------+
| Commit pushed to feature branch          | <- t0
+------------------------------------------+
                      |
                      v
+------------------------------------------+
| PR opened, waiting on review             | <- review wait
+------------------------------------------+
                      |
                      v
+------------------------------------------+
| PR merged to main                        | <- t1
+------------------------------------------+
                      |
                      v
+------------------------------------------+
| Pipeline runs build/test/scan            | <- pipeline run
+------------------------------------------+
                      |
                      v
+------------------------------------------+
| Deploy job completes in production       | <- t2 = lead time
+------------------------------------------+

Code review wait time — how long a pull request sits waiting for a reviewer before it is merged.
Pipeline run time — build, test, and scan stage duration.
Approval gate wait time — time spent waiting for a manual production approval after the pipeline has already passed.
Deployment execution time — the actual rollout duration once approved (rolling update, canary steps, etc).

In most organisations measuring this for the first time, code review wait time and approval gate wait time dominate the total — the pipeline itself is often a small fraction of the overall lead time.

Benchmark Bands

Tier	Lead Time for Changes
Elite	Less than one hour
High	Between one day and one week
Medium	Between one month and six months
Low	More than six months

A team at Zerodha shipping a trading-platform bug fix from commit to production within the hour — automated tests, automated scan, automated deploy to staging, and a fast on-call approval for production — sits in the Elite band. A team where the same fix takes two weeks because of a weekly release train sits in the Medium band, regardless of how fast its actual pipeline runs.

Measuring Lead Time

Compute the difference between the commit timestamp and the production deploy completion timestamp for each change, then take the median (not the mean, which is skewed badly by rare large changes) across a rolling window.

Python

from statistics import median
from datetime import datetime
 
def lead_time_hours(commit_ts, deploy_ts):
    fmt = "%Y-%m-%dT%H:%M:%SZ"
    return (datetime.strptime(deploy_ts, fmt) - datetime.strptime(commit_ts, fmt)).total_seconds() / 3600
 
lead_times = [lead_time_hours(c, d) for c, d in pairs]  # pairs pre-fetched from API
print(f"Median lead time: {median(lead_times):.2f} hours")

Common Bottlenecks and How to Reduce Them

Large pull requests — break work into smaller PRs that can be reviewed and merged within hours, not days.
Slow test suites — separate a fast unit suite that gates every merge from a slower integration/E2E suite that runs less frequently.
Stacked manual approvals — a single production approval gate is reasonable; three separate sign-offs from three different teams for the same change usually is not.
Batched release trains — deploying once a week regardless of how fast individual changes are ready caps lead time at "time until the next scheduled train," not the actual time the change took to build.

Tip
If you only fix one bottleneck first, fix code review wait time — it is usually the largest single contributor and the cheapest to improve (smaller PRs, clearer review ownership, a review SLA).

Remember
Lead Time for Changes and Deployment Frequency are closely related but not the same measurement — a team can have a fast pipeline (short lead time per change) while still batching changes into infrequent releases (low deployment frequency), if changes sit ready but unshipped.

Security
A very short lead time with weak gating can mean security scans are being skipped or treated as advisory rather than blocking. Make sure SAST and dependency scan stages remain blocking gates even as you optimise the rest of the pipeline for speed.

Common Mistake
Measuring lead time only from "PR merged" to "deployed," ignoring the time the PR spent waiting for review. This produces a flattering number that hides the actual largest bottleneck in most organisations.

Troubleshooting Reference

Symptom	Check	What to Look For
Lead time looks unrealistically short	Confirm the start timestamp used	Measurement starting at PR merge instead of first commit
Lead time has huge variance	Compare median vs mean across the window	A few very large, long-reviewed PRs skewing the mean upward
Lead time not improving despite faster pipeline	Break down by phase (review wait, pipeline, approval)	Approval gate or review wait time dominating, not pipeline run time

Frequently Asked Questions

Why does DORA specifically measure lead time from commit to production, rather than from ticket creation?

Measuring from commit isolates engineering and delivery-pipeline efficiency specifically — code review speed, build time, test suite duration, deployment approval friction — separate from upstream planning and prioritization delays that reflect product/business process rather than technical delivery capability. DORA's research classifies elite performers as achieving under one hour and low performers at over six months, making this one of the sharpest performance-tier splits among the four metrics.

What's a common mistake teams make when trying to improve their lead time for changes?

Optimizing pipeline speed (parallelizing tests, caching builds) while ignoring batch size — a change that sits in a feature branch for two weeks accumulating commits before merging will have a long lead time no matter how fast the pipeline runs afterward, because lead time is measured from the first relevant commit. Trunk-based development with small, frequent commits usually moves this metric more than pipeline tooling improvements alone.