Guide
Lead Time for Changes
Lead time for changes measures how long it takes a committed change to reach production. Here is what it is, how to measure it accurately, and how to bring it down.
Lead time for changes is one of the four DORA metrics. It measures the elapsed time between a change being committed to version control and that same change running in production. It answers a blunt operational question: once an engineer has written the code, how long does it take to reach a customer?
Do not confuse it with the broader product "lead time" from idea to delivery, or with cycle time, which usually starts when work begins rather than when a commit lands. DORA's definition is deliberately narrow and technical: commit to deploy. That narrowness is a feature, it isolates the health of your delivery pipeline from the messier upstream work of planning and design.
A short, stable lead time signals small batches, automated testing, and low-friction deployments. A long or erratic lead time usually points to manual gates, batching releases, flaky pipelines, or review bottlenecks. Because it is measured directly from systems you already run, it is hard to game and cheap to collect.
Define the two timestamps precisely
Lead time for changes is a difference between two events, so both must be unambiguous.
- Start: the moment the change is committed. Most teams use the first commit timestamp on the branch, or the merge commit into the trunk. Pick one and stay consistent.
- End: the moment that change is running in production, typically the completion time of the deploy that shipped it.
The trickiest part is attributing a deploy back to the commits it carried. Tagging deploys with the Git SHA range they include makes this attribution reliable rather than approximate.
Instrument your pipeline to emit deploy events
You cannot measure what you do not record. Ensure every production deploy writes an event containing the timestamp, the environment, and the commit SHA (or SHA range) deployed. Sources include your CI/CD system (GitHub Actions, GitLab CI, CircleCI), a deployment tool, or a release webhook.
If you deploy continuously, this is straightforward. If you cut releases manually, capture the release tag and the SHAs it contains so each commit can be joined to its deploy.
Join commits to deploys and compute per-change lead time
For each change, subtract the commit timestamp from the deploy timestamp. Walk the commit graph between consecutive production deploys so every commit is attributed to the first deploy that carried it to production.
Compute this per change rather than per deploy. A single deploy can carry many commits, and each commit has its own lead time depending on how long it waited in the queue.
Report medians and percentiles, never the mean
Lead time distributions are heavily skewed by a small number of long-tail changes (a PR that sat over a holiday, a blocked release). The mean is distorted by those outliers.
- Track the median (p50) for the typical experience.
- Track the 85th percentile (p85) to expose the painful tail your team actually feels.
Use DORA's performance bands as reference points: elite teams deploy in under an hour, high performers within a day, medium performers within a week.
Break the number down to find the bottleneck
A single aggregate hides where time is lost. Decompose lead time into sub-intervals so you know what to fix:
- Commit to PR open - how long code sits on a branch before review is requested.
- PR open to first review - reviewer pickup latency, often the largest chunk. See reducing PR review time.
- Approval to merge - waiting on CI, required checks, or a manual approver.
- Merge to production deploy - release batching and manual deploy gates.
Attack the widest interval first, not the one that is easiest to measure.
Shrink batch size and automate the gates
The most reliable levers for reducing lead time are structural:
- Smaller PRs. Small changes review faster, break less, and merge sooner. This is the single highest-leverage change most teams can make.
- Automate testing and deploys. Replace manual QA sign-off and hand-cranked releases with a trustworthy pipeline so approved code flows to production without human queuing.
- Deploy more often. Continuous deployment collapses the merge-to-production interval toward zero. Deployment frequency and lead time improve together.
- Remove serialized approvals. Replace gatekeeper sign-offs with automated policy checks where risk allows.
Watch the trend and guard against gaming
Lead time is a trend metric, not a target to hit once. Review it weekly alongside the other DORA metrics so you optimize the system, not a single number.
The classic failure mode is cutting lead time by skipping review or tests, which then spikes your change failure rate and MTTR. Always read lead time next to those two so speed improvements are not quietly borrowed from stability. See the full DORA metrics guide for how the four fit together.