What is Lead Time for Changes? Definition, Benchmarks & How to Improve It
June 2, 2026·7 min read·by Ihab Hamdy
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.
DORA Metrics Calculator
See your lead-time tier
Lead time for changes is a core DORA key. Enter your four dimensions to see where your team lands against the 2025 State of DevOps 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
DORA lead time for changes, by performance tier. The metric runs from a commit landing in version control to that change running in production.Source: 2024 State of DevOps Report (DORA).
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.
Frequently asked questions
What is lead time for changes?
Lead time for changes is the elapsed time between a code change being committed to version control and that same change running in production. It is one of the four DORA metrics and a flow metric — it measures how long the path from 'done coding' to 'live for users' actually takes. DORA scopes it deliberately from commit, not from when an idea is conceived, so the number reflects the engineering pipeline a team can control rather than the broader product lead time.
Can you track lead time for changes in Jira?
Jira on its own can't give you DORA lead time for changes, because the metric needs two data points Jira doesn't hold together: the commit timestamp (in GitHub) and the production deploy timestamp (in Vercel or your CI/CD logs). Jira tracks issue workflow, not commit-to-deploy time. You can approximate it by joining those timestamps by hand, but it's tedious enough that most teams never do. An engineering intelligence platform pairs each deployment with the commits it shipped and computes lead time automatically — no manual joins — so a ticketing tool like Jira isn't where this number lives.
