Skip to main content
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

LevelBenchmark
EliteLess than 1 hour
High1 day to 1 week
Medium1 week to 1 month
LowMore 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.
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.

​
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)

Deployment webhook setup

Accurate commit SHAs in your deployment payload are critical for lead time data.