Lead time for changes is one of the four DORA metrics.
It measures the time from a commit landing in version control to that change running in production — the single best measure of how efficiently your delivery pipeline turns work into value.
What is lead time for changes?
Lead time for changes is the elapsed time between a code change being committed and that same change being successfully deployed to production. It is a flow metric: it tells you how long the path from "done coding" to "live for users" actually takes.
Note the precise scope. DORA lead time starts at commit, not at the moment an idea is conceived. Product lead time (idea → production) is a broader concept; DORA deliberately narrows it to the engineering pipeline so the number is something an engineering team can actually control.
Lead time benchmarks
Based on the 2024 State of DevOps Report, lead time for changes falls into four tiers:
- Elite: Less than one day
- High: One day to one week
- Medium: One week to one month
- Low: More than one month (often six months or more)
Elite
Under 1 day
High
1 day – 1 week
Medium
1 week – 1 month
Low
Over 1 month
The gap between Elite and Low is enormous — and it is almost never about how fast people type. It is about how much friction sits between a finished commit and a production deploy.
Lead time vs. cycle time vs. PR cycle time
These three are routinely confused. The distinction matters because they point at different problems:
- Lead time for changes — commit to production. The full pipeline.
- Cycle time — work started to work finished. A broader workflow measure.
- PR cycle time — pull request opened to merged. A slice of lead time, and usually the most actionable one.
What actually moves lead time
If your lead time is high, the cause is almost always one of these:
- Slow code review. PRs sitting unreviewed for days are the most common single contributor. Tracking PR cycle time isolates this.
- Batch deploys. Shipping once a week means a change finished on Monday waits days before it goes out. Smaller, more frequent deploys cut lead time directly.
- Manual release steps. Hand-offs, approval gates, and manual QA all add latency between merge and production.
- Flaky pipelines. A flaky test that forces re-runs adds hours to every deploy.
How to measure lead time without building a pipeline
Most teams never measure lead time because the data is split across systems: commit timestamps in GitHub, deploy timestamps in Vercel or your CI/CD logs. Joining them by hand is tedious enough that it never happens.
An engineering intelligence platform like Deviera computes lead time automatically from the GitHub and Vercel events it already receives — no instrumentation, no manual joins. It pairs each deployment with the commits it shipped and reports lead time benchmarked against the DORA tiers above. You can also get a one-time read with the free DORA calculator.
For the bigger picture of how lead time fits alongside the other metrics that predict delivery performance, see our guide to engineering metrics.