CodeKuduCodeKudu

Lead time for changes

In the DORA framework, lead time for changes is the time from a commit reaching the mainline to that change running successfully in production—though teams adapt the exact boundaries.

Definition

Lead time for changes is one of the four DORA metrics. It measures how long it takes to go from code committed (or integrated into the trunk or main branch) to that change running in production in a healthy state.

DORA uses this metric to reflect delivery efficiency and batch size: shorter lead times usually correlate with smaller, safer changes and stronger automation—but industry and architecture matter; a mobile app release train will look different from a continuous web deploy.

How teams typically measure it

  • Typically: timestamp of the commit (or merge to default branch) to timestamp of successful production deployment containing that change.
  • Monorepos and feature flags complicate attribution; some teams measure “first production exposure” when a flag is enabled.
  • If you do not deploy continuously, the clock may include release approval windows—those are process choices, not “bad engineering.”

Common pitfalls

  • Comparing raw numbers to published DORA elite/high/medium/low thresholds without matching industry, product type, and regulatory context. Those bands are research summaries, not performance targets for individuals.
  • Equating lead time with developer speed alone. Waiting for QA slots, change boards, or infrastructure is often the dominant factor.

Related terms

Browse other entries in the glossary.