What Is Lead Time for Changes?
Lead time for changes is a DORA metric that measures the elapsed time from a code change being committed to that change running in production.
Lead time for changes captures how quickly your delivery system turns work into value for users. A short lead time means feedback loops are tight and the path to production is well-oiled; a long one usually hides waiting, manual steps, or fragile processes.
Defining the clock
Lead time for changes starts when code is committed and stops when it is successfully running in production. It deliberately excludes the time spent designing or deciding what to build, focusing instead on the delivery pipeline -- the part teams can most directly engineer.
Where the time goes
Lead time is the sum of many smaller waits: code review, CI build and test runs, queueing for runners, approvals, and the deployment itself. Mapping where the hours actually go usually reveals that most of the elapsed time is waiting, not working.
CI speed is a major factor
For many teams, the pipeline is the largest controllable chunk of lead time. Slow builds, long test suites, and jobs waiting in a queue for a runner all add up. Faster, more parallel CI and avoiding flaky reruns can compress lead time substantially. A managed runner platform that reduces queue time and recovers from transient failures can directly improve this metric.
Shortening it safely
The right way to cut lead time is to remove waste, not safety. Smaller changes, automated testing, trunk-based development, and parallelized pipelines all shorten the clock while keeping or improving quality. Skipping review or tests would shorten it too, but at the cost of the stability metrics.
What good looks like
Elite teams measure lead time in hours or less; lower performers measure it in weeks or months. The exact target matters less than the trend: a steadily shrinking lead time signals a healthier, more responsive delivery system.
Key takeaways
- Lead time for changes is the elapsed time from commit to running in production.
- Most of it is usually waiting -- in review, queues, and slow CI.
- Shorten it by removing waste and speeding the pipeline, not by skipping safety.