Lead Time for Changes
Lead Time for Changes measures the time it takes for a committed code change to reach production. Specifically, it is the duration from when a developer commits code to when that code is successfully running in production. It is a core DORA metric that reflects the efficiency of an engineering team's delivery pipeline.
Formula
Lead Time for Changes = Production deployment timestamp − First commit timestamp For PR-based workflows: Lead Time = Deployment time − PR first-commit time For issue-linked workflows: Lead Time = Deployment time − Issue start time (time the issue moved to "In Progress") Aggregate lead time = Median lead time across all changes in the time period. Use the median, not the mean — outliers (e.g., long-lived feature branches) skew the mean significantly.
Industry Benchmarks
| Performance Level | Benchmark (hours / days) |
|---|---|
| Elite | Less than one hour |
| High | Between one day and one week |
| Medium | Between one week and one month |
| Low | More than six months |
Benchmarks from the 2023 State of DevOps Report (DORA). Note the wide gap between Elite (< 1 hour) and High (< 1 week) — this reflects the compounding value of automated pipelines, trunk-based development, and small batch sizes.
Data Sources
- GitHub: PR creation timestamp, first commit timestamp, and merge timestamp
- Vercel, Railway, Netlify, Render, Fly.io, AWS CodeDeploy: production deployment timestamps
- Jira or Linear: issue start timestamps for end-to-end lead time (issue-to-deploy)
- GitHub Actions: CI pipeline duration as a sub-component of lead time
Why Lead Time for Changes matters
Short lead time means feedback loops are tight. When a bug fix reaches production in minutes rather than days, engineers learn faster whether their change worked, whether it caused a regression, and whether the underlying issue is resolved. Lead time is also a proxy for organizational agility: teams with short lead times have eliminated manual approvals, long-running test suites, and deployment windows that force batching. From a business perspective, short lead time means features reach customers faster and competitive advantages are not eroded by slow release cycles.
Common measurement mistakes
Measuring lead time only from PR open to merge, omitting the time from merge to deployment. For many teams, the pipeline from merge to production is longer than the development cycle itself — trunk to prod can take hours or days in organizations without continuous deployment.
Using the mean instead of the median. A single long-lived feature branch skews the mean dramatically. The median is a much more representative measure of typical delivery speed.
Including work-in-progress branches in the calculation. Only commits that successfully reach production should be counted. Abandoned branches inflate lead time measurements artificially.
How Koalr measures Lead Time for Changes
Koalr measures lead time as the duration from a PR's first commit to the deployment event that includes that commit's SHA. GitHub's Deployments API provides deployment SHA references; Koalr traces backwards to the first commit in the PR. For organizations using Jira or Linear, Koalr extends the measurement back to when the linked issue moved to "In Progress," providing an issue-to-deploy view alongside the commit-to-deploy view. Koalr displays median lead time per team, per repository, and organization-wide.
Related DORA metrics
See your Lead Time for Changes in Koalr
Connect GitHub and your deployment platform to start tracking all four DORA metrics automatically. No manual data entry, no spreadsheets.