Lead Time for Changes: What It Is and How to Calculate It

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.

Why it matters

Lead time is the metric that turns "we're working on it" into an actual promise. A bug report or a customer request doesn't feel resolved when someone starts writing code for it — it feels resolved when the fix is live. A team with a lead time measured in days can credibly tell a customer "this will be fixed this week"; a team with a lead time measured in months can only say "it's in the queue," because that's genuinely all they know. Shortening lead time is one of the few engineering investments that shows up directly as a better answer to "when will this ship."

It's also a diagnostic, not just an outcome. A long lead time is rarely one big bottleneck — it's usually several smaller ones stacked up: code sitting unreviewed, a test suite that takes hours, a deploy process that needs a person to babysit it. Measuring the number regularly is what surfaces which of those is actually the biggest one to fix first, instead of guessing.

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.

A quick example: 10 pull requests merge in a week, with lead times (commit to production) of 2h, 3h, 4h, 5h, 6h, 8h, 10h, 12h, 20h and 96h — one PR that sat waiting on a delayed release window. The median is 7h, which is what a typical change actually experiences. The average, 16.6h, is pulled up almost entirely by that one outlier — reporting only the average here would make a fast week look slow.

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.

A common trap

Starting the clock at merge instead of at first commit makes lead time look better without the pipeline actually getting any faster — it just stops counting the time a change spent in review, which is often where the real delay lives. Neither starting point is wrong, but it's worth being explicit about which one a team is using before comparing the number over time or between teams.

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