Lead time for changes

How is lead time for changes measured?

Lead time for changes is the wall-clock interval between two events: the moment a change is committed to version control and the moment that same commit is running in production. Most teams report the median across a window (weekly or monthly), because the distribution is heavily skewed: a handful of long-running features can drag the mean into the noise.

Two decisions decide the number:

1. When does the clock start? DORA and most practitioner literature use the first commit associated with the change, not the moment a ticket was opened or a PR was created. Starting earlier (ticket-open) turns the metric into "cycle time" and mixes engineering time with product-backlog time; starting later (PR-opened) hides slow local branch work. Pick "first commit hits a shared branch" and stick with it.
2. When does the clock stop? When the commit is running in production and reachable by users, not when the artifact was built, not when the deploy job passed a health check. Code that ships dark behind a feature flag still counts as deployed; a flag flip is a release, not a deploy.

The DORA State of DevOps reports group teams into bands:

Band	Lead time for changes
Elite	Less than one hour
High	Between one day and one week
Medium	Between one week and one month
Low	Between one month and six months

Treat the bands as a direction signal, not a leaderboard. A safety-critical firmware release will never sit "under an hour" and shouldn't try. What matters is whether the trend for your service is moving where you intend, and whether it agrees with the other three DORA metrics.

Why does lead time for changes matter?

Lead time is the most sensitive of the four DORA metrics to how your pipeline actually feels. Deployment frequency tells you whether you ship; change failure rate tells you whether releases stick; MTTR tells you whether incidents end quickly. Lead time is the one that tells you whether a normal, low-risk change reaches users while it is still relevant, or waits three weeks behind more important work in a review queue.

Two things reliably shrink it:

• Smaller batches. A change touching five files can be reviewed in fifteen minutes; one touching ninety cannot. Adopting trunk-based development and short-lived branches is the single biggest lever. It does not "make CI faster", it shrinks the object CI has to check.
• Parallel, cached CI. A pipeline where lint, unit tests, integration tests and image build all run in parallel finishes in the wall-clock of the slowest job, not the sum. Add a shared dependency cache and typical CI drops from ~15 minutes to ~4.

And two things reliably inflate it, both of which have nothing to do with the pipeline:

• Review latency. A PR sitting in review is invisible to the CI graph but very visible to lead time. The most common cause of a "slow pipeline" complaint is actually humans, not bytes.
• Approval chains and release windows. A change ready to ship on Wednesday morning but held until the Thursday-afternoon release train has, on paper, a 30-hour lead time, regardless of how fast the pipeline runs.

One honest caveat: very short lead time on its own is not the goal. A team that pushes to prod in ninety seconds but skips tests will look elite on lead time and terrible on change failure rate. Always read this number next to CFR and MTTR. The DORA quartet was designed to be read together, and any three of the four can be gamed by ignoring the fourth.

How do popular CI/CD tools help you shorten lead time?

The raw events (commit timestamp, deploy timestamp) live in your VCS and CI/CD; the interesting question is which tool best removes the reasons lead time is long: batch size, review wait, and slow CI.

• GitHub Actions + GitHub: the tightest coupling of code, pull requests and CI in the market. Merge queues, required checks, code-owner routing and re-usable workflows shorten the review-and-test half of lead time; the pulls timeline API plus the deployments API is enough to compute the metric with a single scheduled workflow. If your bottleneck is review latency, GitHub's merge queue and CODEOWNERS routing are the honest winner. No separate CI tool can beat living where the pull requests already are.
• GitLab CI: Value Stream Analytics on Premium/Ultimate computes lead time end-to-end from merge-request and deployment records, with the coding → review → CI → deploy segmentation already broken out. If you are already on GitLab, that dashboard is the cheapest credible view you can get.
• CircleCI: Insights surfaces per-job duration and flaky-test data, which is where the pipeline half of lead time actually leaks. Their parallelism/test-splitting features are genuinely strong for teams whose CI has crept past ten minutes and are looking for the shortest path to five.
• Argo CD / Argo Rollouts: Kubernetes-native declarative delivery. Application sync events plus a community DORA dashboard produce clean lead-time charts alongside cluster telemetry. If you are all-in on Kubernetes and manifests already live in Git, Argo is the natural fit and beats bolting the same behaviour on top of a generic CI runner.
• Specialised DORA platforms: Sleuth, LinearB and Jellyfish pull events from VCS, CI/CD and the incident tracker and decompose lead time into coding, review, CI and deploy segments across the whole org. Worth the money once "which step is slow" is a serious question spanning dozens of teams.
• Buddy is one solid option when the bottleneck is the pipeline half of lead time: the CI + deploy minutes between merge and production. Parallel actions, a persistent workspace cache and ON_EVERY_PUSH triggers let a small team wire a push-to-prod pipeline where lint, unit tests, image build and integration tests fan out in parallel and deploy fires the moment the slowest one is green. The org-wide dashboard still lives elsewhere; Buddy's role is to keep the CI-half of the lead-time bar honest.

There is no single winning tool here. Diagnose which segment of lead time is longest (coding, review, CI or deploy) before picking a tool. Chasing the number by stacking another dashboard on top of the same slow review process is the classic anti-pattern.

Example

A minimal Buddy pipeline that ships every push to main, then computes the lead time for that specific commit by taking the delta between the commit's Git author timestamp and the deploy's finish time, and posts it as one point in the lead-time series. No agent, no separate collector.

# .buddy/buddy.yml — deploy on push AND emit a lead-time datapoint per change
- pipeline: "deploy-production"
  events:
    - type: "PUSH"
      refs:
        - "refs/heads/main"
  variables:
    - key: "SERVICE"
      value: "checkout-api"
    - key: "METRICS_ENDPOINT"
      value: "https://metrics.example.com/lead-time"
  actions:
    - action: "Build & deploy"
      type: "BUILD"
      docker_image_name: "node"
      docker_image_tag: "20"
      commands: |-
        npm ci
        npm run test:unit
        npm run build
        ./scripts/deploy.sh

    - action: "Record lead time for this change"
      type: "BUILD"
      docker_image_name: "alpine"
      docker_image_tag: "3"
      commands: |-
        apk add --no-cache git curl
        COMMIT_TS=$(git show -s --format=%ct ${BUDDY_EXECUTION_REVISION})
        DEPLOY_TS=$(date +%s)
        LEAD_TIME=$((DEPLOY_TS - COMMIT_TS))
        curl -X POST "${METRICS_ENDPOINT}" \
          -H "Content-Type: application/json" \
          -d "{\"service\":\"${SERVICE}\",\"commit\":\"${BUDDY_EXECUTION_REVISION}\",\"lead_time_seconds\":${LEAD_TIME},\"deployed_at\":\"${BUDDY_EXECUTION_FINISH_DATE}\"}"

The lead-time dashboard reads from ${METRICS_ENDPOINT} and plots the median across a rolling window. Because the number is computed inside the pipeline against the actual commit that just deployed, it is immune to the two common measurement mistakes: averaging across merged-but-undeployed commits, or stopping the clock at "artifact built" instead of "running in production". Whatever ends up on the org chart, the source of truth is one HTTP POST per successful release.