Calculator inputs
Use actual timestamps when available. Use stage durations when you want a modeled estimate or a bottleneck breakdown.
Example data table
These sample rows show how cloud delivery delays can accumulate even when pipeline execution is fast.
| Team | Commit | Production | Review Wait (h) | Build (min) | Test (min) | Approval (h) | Queue (h) | Total Lead Time |
|---|---|---|---|---|---|---|---|---|
| Platform A | 2026-04-08 09:00 | 2026-04-08 23:00 | 3.0 | 18 | 42 | 1.5 | 2.0 | 14.0 h |
| Hosting Ops | 2026-04-05 11:30 | 2026-04-07 10:00 | 10.0 | 25 | 55 | 6.0 | 12.0 | 46.5 h |
| Edge Services | 2026-04-01 08:15 | 2026-04-04 16:15 | 14.0 | 30 | 65 | 8.0 | 20.0 | 80.0 h |
Formula used
Use actual timestamps for the cleanest measurement. Use stage inputs to estimate modeled lead time and identify bottlenecks.
Actual Lead Time (hours) = (Production Timestamp − Commit Timestamp) ÷ 3600
Modeled Lead Time (hours) = Development + Review Wait + Build + Test + Scan + Approval Wait + Release Queue + Staging + Deployment + Rework
Build, Test, Scan, Staging, and Deployment hours = Minutes ÷ 60
Active Handling Time = Development + Build + Test + Scan + Staging + Deployment
Waiting Time = Review Wait + Approval Wait + Release Queue + Rework
Flow Efficiency (%) = Active Handling Time ÷ Lead Time × 100
Delay Share (%) = Waiting Time ÷ Lead Time × 100
How to use this calculator
- Enter the commit timestamp for the change entering delivery flow.
- Add merge and production timestamps if your team tracks real event times.
- Fill stage delays to model review, pipeline, approval, queue, and rollout time.
- Submit the form to see lead time, delay share, flow efficiency, and bottleneck stages.
- Download the summary as CSV or PDF for reporting, retrospectives, or team reviews.
Frequently asked questions
1. What is deployment lead time?
Deployment lead time measures how long a change takes to move from commit into production. It highlights delivery speed and exposes delays in reviews, approvals, testing, queues, and rollout steps.
2. Which timestamp should I use for the start?
Use the commit timestamp that best represents when the change entered delivery flow. Teams often use the first commit, merge request creation, or merge commit, depending on reporting policy.
3. Should I enter production time or stage durations?
Enter production time when you have actual release timestamps. Enter stage durations when you want a modeled estimate or need to understand how specific delays contribute to total lead time.
4. Why can actual and modeled lead time differ?
Actual timestamps capture real elapsed time. Modeled values depend on the delays you entered. Differences usually mean there are untracked waits, overlapping stages, or assumptions that need refinement.
5. What does flow efficiency mean here?
Flow efficiency shows the share of total lead time spent on active work rather than waiting. A lower percentage usually means approvals, queues, or rework are slowing your delivery system.
6. Can this compare different teams or services?
Yes. Use the same input rules for every team, service, or repository. Consistent measurement makes comparisons more useful and prevents differences caused only by inconsistent timestamp definitions.
7. Does rework change the lead time result?
Yes. Rework or incident delay extends overall lead time and reduces flow efficiency. Tracking it separately makes change failure impact visible during delivery reviews and improvement planning.
8. What is considered a good lead time?
A good value depends on release risk, compliance, and system complexity. In general, shorter lead time with low rework is better because it indicates faster feedback and smoother delivery flow.