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 is calculated

When a deployment event arrives with status: "success" and environment: "production", Periscope:
  1. Matches the deployment’s commitSha against the mergeCommitSha of pull requests in the database
  2. If previousCommitSha is provided, also links all PRs merged between the previous and current commit
  3. For each linked PR, calculates lead_time_seconds = deployment.completedAt - pr.mergedAt
  4. Stores this in the deployment_pull_requests join table for fast querying
The percentile values (p50, p75, p95) are computed across all deployment-PR links 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.