Skip to main content

​
How it works

PR deploy lead time measures the elapsed time between when a pull request is merged and when its change is first confirmed in production. The clock includes time waiting in a deployment queue, release window, or batch; it does not start when a workflow begins. This metric is also known as “deployment lead time” and is one of the four key DORA metrics. Lower lead times indicate:
  • Fast CI/CD pipelines
  • Automated deployment processes
  • Minimal manual release processes
  • Continuous deployment practices

​
Calculation

The metric measures the elapsed time from PR merge to production deployment. Formula:
The chart reports the median of eligible PR lead times, including the median for the entire selected period. A few changes that wait several hours can therefore coexist with a lower period median; the chart is not an average or a maximum.

​
How deployments are linked to PRs

Weave connects PRs to deployments by:
  1. Commit tracking: Identifying the commit each deployment run deployed (or, for verified batch releases, the full deployed commit range)
  2. PR mapping: Linking commits back to their source PRs
  3. Time calculation: Measuring the time from PR merge to deployment completion

​
Multiple PRs in one deployment

When a deployment includes multiple PRs:
  • Each PR’s individual deploy lead time is calculated
  • The metric shows the median across all eligible PRs
  • Individual PR lead times are available in drill-down views
For GitHub Actions workflows without deployment-confirmation jobs configured, Weave retains the existing workflow-completion detection behavior. For a configured workflow, the selected job names identify the actual production confirmation boundary: a successful workflow alone does not count if the selected release work did not run and succeed. A configured successful workflow whose confirmation jobs were all skipped is a no-op and does not count as a deployment. Missing or incomplete job evidence remains unknown/pending; it is not inferred to be a successful deployment or a no-op. To attribute a canceled change to a later batch release, configure Batch releases since on a GitHub Actions workflow that also has deployment confirmation job names, and only for a release stream whose verified baseline and complete deployed commit range can be checked. A later successful workflow alone does not prove that it included earlier changes. Until cumulative coverage is verified, those changes remain unresolved rather than being assigned an invented deployment time.

​
Industry benchmarks

Based on DORA research:

​
Why it matters

Deploy lead time reflects:
  • Pipeline efficiency: How fast your CI/CD pipeline runs
  • Release process: Whether you batch changes or deploy continuously
  • Time to value: How quickly users benefit from new code
  • Feedback loops: How soon developers learn if their changes work in production
Long lead times often indicate:
  • Manual approval gates
  • Scheduled release windows
  • Slow CI/CD pipelines
  • Large batch sizes

​
Common patterns

​
Continuous deployment (CD)

  • PRs deploy to production automatically after merge
  • Lead time: Minutes to hours
  • Best for: SaaS products, web applications

​
Scheduled releases

  • PRs accumulate and deploy in batches
  • Lead time: Days to weeks
  • Best for: Mobile apps, embedded systems

​
Hybrid approach

  • High-priority fixes deploy immediately
  • Features deploy on schedule
  • Lead time: Mixed (minutes for hotfixes, days for features)

​
Improving deploy lead time

To reduce PR deploy lead time:
  1. Optimize CI/CD pipeline:
    • Parallelize test execution
    • Cache dependencies
    • Optimize build times
    • Remove unnecessary steps
  2. Automate deployments:
    • Enable automatic deployment on merge
    • Remove manual approval gates (where safe)
    • Use trunk-based development
  3. Reduce batch size:
    • Deploy PRs individually or in small batches
    • Avoid accumulating PRs for weekly releases
    • Use feature flags for incomplete features
  4. Improve testing confidence:
    • Expand automated test coverage
    • Add smoke tests and health checks
    • Monitor deployment success rates
  5. Remove process bottlenecks:
    • Eliminate manual release approval steps
    • Automate release notes generation
    • Use GitOps for infrastructure changes
Fast deploy lead times require confidence in your testing and monitoring. Don’t sacrifice quality for speed - invest in automated testing and observability first.

​
Technical details

Weave links PRs to deployments through each deployment run’s commit:
  1. Deployment commit: Read the commit SHA (and the PR number, when the CI/CD platform reports it) of each production run
  2. PR mapping: Find the PRs that contain that commit, using your Git provider’s data
  3. First deployment: Use the earliest successful production run linked to each PR
  4. Lead time calculation: Measure time from PR merge to deployment completion
PRs merged earlier that a later run doesn’t link to stay unresolved, unless you configure Batch releases since for a GitHub Actions workflow, which checks each verified release’s full commit range. Azure DevOps classic releases don’t carry a commit, so they don’t link to PRs.
Weave doesn’t filter this metric by branch. Every merged PR that’s linked to a successful run of a production-classified workflow counts:
  • Tracked: PRs on any branch, unless you set up Settings → Branch whitelists, which apply to all PR metrics
  • Excluded: Runs of workflows that aren’t classified as production, such as preview or staging workflows. The classification considers the branches each workflow runs on
  • GitLab: If you turn on the default-branch rule, pipelines on each project’s default branch count as production deployments
This ensures the metric reflects production deployment lead time.
Only the first production deployment is counted:
  • First deployment: Used for lead time calculation
  • Subsequent deployments: Ignored (not a “new” deployment)
  • Rollbacks: Not counted as deployments
This prevents artificially inflating lead times from re-deployments.
PR deploy lead time requires:
  • Git repository data: PR merge times and commit history
  • CI/CD platform data: Deployment timestamps and commit ranges
  • Supported platforms:
    • Git: GitHub, GitLab, Bitbucket, Azure DevOps
    • CI/CD: GitHub Actions, GitLab CI/CD, Azure DevOps (build pipelines), CircleCI, Jenkins, Argo CD
Lead time is calculated as the median (not mean) of all PR deploy times:
  • Daily: Median lead time for PRs merged that day
  • Weekly: Median lead time for PRs merged that week
  • Monthly: Median lead time for PRs merged that month
  • Selected period: Median lead time across all eligible PRs merged in the selected period
The chart’s headline is the selected-period median. Median is less sensitive to outliers (for example, a PR that waited hours or days before deployment), so it can be lower than some individual PR values.

​
Public API

Available from GET /metrics as pr_deploy_lead_time: median time in seconds from PR merge (or treat-closed-as-merged) to the first successful production deploy of that PR. Queue time is included. PRs without confirmed deployment evidence are omitted from the numeric metric and remain unresolved in deployment coverage; they are not assigned a guessed completion time. Requires a CI/CD connection and production-classified workflows. Supports group_by of team, account, project, and pr_type.
Last modified on October 17, 2026