Lead Time for Changes Calculator
Calculate the DORA lead time for changes from commit to production deployment.
Inputs
Average elapsed time from a commit landing on the main branch to it being deployed to production.
How many recent deployments this average was computed across, for context on sample size.
Lead Time for Changes
8.00hours
Lead Time for Changes
0.33days
DORA Category
High (less than one day)
Sample Size
20deployments
Step by step
Lead time in minutes
8 × 60
= 480 min
Lead time in days
8 ÷ 24
= 0.33 days
DORA classification
8 hours
= High (less than one day)
How it works
Lead Time for Changes is a core DORA metric measuring the time from code committed to code successfully running in production: lead_time = deploy_time − commit_time, averaged across a sample of recent deployments. DORA performance tiers classify this as Elite (under 1 hour), High (under 1 day), Medium (between 1 day and 1 month), and Low (over 1 month) — shorter lead times indicate a more efficient, less risky delivery pipeline.
Formula
leadTimeDays = avgCommitToDeployHours / 24
- L_h
- Average commit-to-deploy time in hours
- L_d
- Lead time for changes in days
Frequently Asked Questions
Should lead time start from the first commit on a feature branch or the merge to main?
DORA's definition specifically measures from merge to main (i.e. code committed to the trunk/main branch) to production deployment — time spent on a long-lived feature branch before merging isn't counted.
How is lead time for changes different from cycle time?
Cycle time often includes the full development process starting from work beginning (e.g. ticket picked up); DORA's lead time for changes starts specifically at commit-to-main, a narrower and more consistently measurable window.
What drives most of the lead time in slow pipelines?
Commonly: slow or flaky CI pipelines, manual approval gates, batch/scheduled deployment windows instead of continuous deployment, and large batch sizes that require more testing and review before shipping.
Why average across many deployments instead of using one sample?
Individual deployments can vary widely due to one-off circumstances (a hotfix vs. a large feature); averaging over a rolling window of recent deployments gives a more representative and stable metric.
You might also need
- Mean Time to Recovery MTTR CalculatorCommonly used together
- Deployment Frequency CalculatorCommonly used together
- DevOps Maturity Score CalculatorCommonly used together
- Release Velocity CalculatorCommonly used together
- Sprint Burndown CalculatorCommonly used together
- Deployment Frequency CalculatorCommonly used together