Skip to main content
Glossary

What Are Lead Time for Changes?

A DORA metric that measures the elapsed time from a developer's first commit to that code running in production. Elite teams achieve lead times under one day.

2-minute setup • No credit card required

What it means

Lead time for changes captures the entire delivery pipeline — coding, code review, CI/CD, testing, and deployment. It starts when a developer makes the first commit on a feature branch (or the first commit toward a change) and ends when that code is deployed to production and serving users. This metric reveals bottlenecks that aren't visible in any single stage: a team might have fast CI (10 minutes) but 3-day code reviews, resulting in a 3.5-day lead time. Lead time is distinct from cycle time (which often starts when work begins on a ticket) and deployment frequency (which measures how often you deploy, not how long each change takes). The DORA benchmarks classify lead time as: Elite (less than 1 day), High (1 day to 1 week), Medium (1 week to 1 month), Low (more than 1 month).


Why Lead Time for Changes matter

Lead time for changes is the most actionable DORA metric for engineering managers because it directly maps to process steps that can be optimized. When lead time is high, you can decompose it into stages: time spent coding, time waiting for review, time in CI, time waiting for deployment approval. Each stage has specific fixes. Long review times? Add review SLAs or pair programming. Slow CI? Parallelize tests or add caching. Manual deployment gates? Automate them. Reducing lead time also improves developer satisfaction — engineers want to see their work in production quickly, not wait days for a review or a deployment window.


How to measure

Track two timestamps for each change: (1) the first commit timestamp on the branch or PR, and (2) the production deployment timestamp that includes that change. The difference is your lead time. Calculate the median across all changes in a time period (weekly or monthly). Use git data for commit timestamps and CI/CD data for deployment timestamps. Tools like Gitmore, LinearB, and Sleuth can calculate this automatically. For accuracy, exclude reverted changes and measure only successful deployments.


Real-world example

A fintech team has a 5-day average lead time. Breaking it down: coding takes 1 day, PR review takes 2.5 days (reviewers are overloaded), CI takes 25 minutes, and deployment happens in a weekly batch on Fridays. Two changes bring lead time to 1.5 days: (1) they set a 24-hour review SLA with rotating reviewers, cutting review time to 1 day, and (2) they switch from weekly to daily deployments via automated pipeline. Now code ships the day after it's written.

FAQ

Common questions

What's the difference between lead time and cycle time?

Lead time for changes (DORA) measures commit-to-production. Cycle time typically measures ticket-start to ticket-done, which includes planning and prioritization time before coding begins. Lead time is more focused on the engineering delivery pipeline, while cycle time includes product and project management stages.

What is a good lead time for changes?

DORA benchmarks: Elite teams have lead times under 1 day, High performers between 1 day and 1 week, Medium between 1 week and 1 month, Low over 1 month. For most SaaS teams, getting under 1 week is a realistic first target. Elite-level (under 1 day) requires trunk-based development and automated deployment.

What causes high lead time?

The most common bottlenecks are: slow code reviews (reviewers overloaded or not prioritizing reviews), long-running CI pipelines (>30 minutes), manual QA gates, deployment windows (weekly or bi-weekly releases), large PRs that take longer to review and test, and approval processes that add wait time.

Should you measure lead time per team or per repo?

Measure per team first, since that's what you can act on. A team owns their review process, CI configuration, and deployment pipeline. Per-repo metrics are useful for monorepos where different services have different pipelines. Avoid comparing lead times across teams with different contexts (e.g., mobile vs. backend).

Track Lead Time for Changes Automatically

Gitmore turns your git activity into automated reports with real metrics — delivered to Slack and email.

Get Started Free

No credit card • No sales call • Reports in 2 minutes