GUIDE
Lead Time for Changes: What It Is and How to Calculate It
One of the 4 DORA metrics — how long it takes a commit to reach production.
What it measures
Lead time for changes is the time between a piece of code being committed (or merged) and that same code running in production. It's a direct measure of how fast a fix or a feature can actually reach a user — not how fast someone can write the code, but how long the rest of the pipeline (review, testing, deployment) takes once the code is ready.
How to calculate it
For each change, measure the time between the commit (or merge to main) and the deploy that first included it in production, then look at the distribution across changes over a period — median matters more here than average, since a handful of unusually slow changes can otherwise skew the number. A single "lead time" that's really an average of very different change sizes (a one-line fix vs. a multi-week feature) tends to be less useful than looking at the median and the spread together.
Elite vs. typical performance
Elite performers typically get a change into production in under a day. Teams in the middle often take somewhere between a day and a week, sometimes up to a month. Lower performers can take a month or more. As with deployment frequency, treat these as a general sense of scale rather than a strict scorecard — the exact bands have shifted slightly across different years of the State of DevOps Report.
How moasy.tech computes it
moasy.tech recalculates lead time for changes automatically from what's already synced from GitHub, GitHub Actions, ArgoCD, Vercel and Azure Pipelines — read-only, no manual timestamp hunting. Which event starts the clock (a commit, a merge, a PR opening) is configurable per team, with a company-wide default as fallback, so two teams with different workflows can each measure the same concept correctly instead of forcing one definition on both.
See the other 3 DORA metrics in the full guide, or the complete implementation on the DORA Metrics feature page.
Questions about lead time for changes
Is lead time for changes the same as cycle time?
Related, but not identical. Cycle time (a Flow Metric) usually starts when work begins on an item — moving a ticket to "In Progress", for example. Lead time for changes starts later, at the commit or merge, and ends specifically at a production deploy. Cycle time answers "how long does work take", lead time for changes answers "how fast can a ready change ship". See the Cycle Time guide for the Flow Metrics side of this.
Does code review time count?
Yes, if you start the clock at commit or PR open rather than at merge — review time is part of what makes lead time long or short. Starting the clock at merge instead simply narrows what the metric captures; either is a valid choice as long as it's applied consistently.