> ## Documentation Index
> Fetch the complete documentation index at: https://docs.weaveos.com/llms.txt
> Use this file to discover all available pages before exploring further.

# PR deploy lead time

> Time from PR merge to first production deployment

## 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](https://dora.dev/guides/).

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:**

```
PR Deploy Lead Time = Confirmed Production Deployment Time - PR Merge Time
```

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:

| Performance Level | Deploy Lead Time |
| - | - |
| **Elite** | Less than 1 hour |
| **High** | 1 hour to 1 day |
| **Medium** | 1 day to 1 week |
| **Low** | More than 1 week |

## 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

<Note>
  Fast deploy lead times require confidence in your testing and monitoring. Don't sacrifice quality for speed - invest in automated testing and observability first.
</Note>

## Technical details

<AccordionGroup>
  <Accordion icon="link" title="How are PRs linked to deployments?">
    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.
  </Accordion>

  <Accordion icon="code-branch" title="Which branches are tracked?">
    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.
  </Accordion>

  <Accordion icon="stopwatch" title="What if a PR is deployed multiple times?">
    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.
  </Accordion>

  <Accordion icon="chart-line" title="What data sources are used?">
    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
  </Accordion>

  <Accordion icon="calendar" title="How is the metric aggregated?">
    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.
  </Accordion>
</AccordionGroup>

## Public API

Available from [`GET /metrics`](/api-reference/metrics/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`.

## Related metrics

* **[CI deploy frequency](/metrics/ci-deploy-frequency):** How often you deploy
* **[PR cycle time](/metrics/pr-cycle-time):** Time from first commit to merge
* **[PR merge time](/metrics/pr-merge-time):** Time from PR open to merge
* **[CI deploy success rate](/metrics/ci-deploy-success-rate):** Deployment reliability


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.