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

# Lead time for changes

> Time from PR merge to production deployment. The second DORA metric and a key measure of delivery speed.

Lead time for changes measures the elapsed time between a pull request being merged and the deployment containing that change reaching production. It captures the full delivery pipeline — from "code complete" to "live in production."

## What Periscope tracks

Periscope computes lead time by linking deployment events to merged pull requests via commit SHA. The dashboard shows:

* **Percentiles** — p50, p75, and p95 lead times
* **Average, minimum, and maximum** lead times
* **Individual PR data** showing which pull requests had the longest lead times
* **Trend over time** to track whether your pipeline is getting faster or slower

## DORA benchmarks

| Level      | Benchmark         |
| ---------- | ----------------- |
| **Elite**  | Less than 1 hour  |
| **High**   | 1 day to 1 week   |
| **Medium** | 1 week to 1 month |
| **Low**    | More than 1 month |

## How it works

Periscope automatically links deployments to merged pull requests using the commit SHA in your deployment payload. For each linked PR, lead time is measured from the moment the PR was merged to when the deployment containing that commit reached production.

The dashboard shows percentile values (p50, p75, p95) computed across all linked PRs in the selected time range.

<Info>
  Lead time requires both GitHub connected (for PR merge data) and deployment events with accurate `commitSha` values. If your commit SHAs do not match your PR merge commits, lead time data will be incomplete.
</Info>

## Interpreting the data

* **p50 (median)** represents the typical experience. This is the number most teams should focus on improving.
* **p95** represents the worst-case tail. A large gap between p50 and p95 often means specific services or deployment paths are significantly slower than others.
* **High lead time with high deployment frequency** suggests deployments happen often but only after batching changes, possibly due to a scheduled release train.
* **Decreasing lead time** is the strongest signal that your delivery pipeline is improving.

### Common causes of high lead time

* Manual approval gates between merge and deploy
* Long-running CI/CD pipelines
* Deployment queues (too many services sharing a pipeline)
* Code freezes or batched release cadences
* Merge-to-main doesn't trigger a deploy (requires manual intervention)

## MCP tool

Query lead time from your AI coding assistant:

```
get_lead_time(time_range: "30d")
```

Returns p50, p75, p95, average, min, max, and up to 15 sample PRs with their individual lead times.

You can also find the worst offenders:

```
get_slowest_lead_times(time_range: "30d", limit: 10)
```

<Card title="Deployment webhook setup" icon="webhook" href="/integrations/deployment-webhook">
  Accurate commit SHAs in your deployment payload are critical for lead time data.
</Card>