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
+------------------------------------------+| 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.
from statistics import medianfrom 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 APIprint(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.
PLACEMENT PRO TIP**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 THIS**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.
COMMON MISTAKE / WARNING**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 / WARNING**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 |