Log in Get started
Metric · DORA

What is lead time for changes, and how do you measure it in Metabase?

Lead time for changes is the time from a commit to that code running in production. It's the DORA throughput metric for delivery speed, and pairs with deployment frequency. Measure it in Metabase by joining commits to the deploy that shipped them, using GitHub or GitLab data.

TL;DR — Commit timestamp → production deploy timestamp, reported as a median (and p90). Different from "lead time" on an issue and from cycle time.

What lead time for changes measures

It captures how long code waits between being written and reaching users: review, CI, queueing, and release. Shorter lead time means smaller batches and faster feedback. Use median and p90 — the distribution is right-skewed, so averages mislead.

Lead time for changes vs. lead time vs. cycle time

MetricStartsEnds
Lead time for changes (DORA)Code committedDeployed to production
Lead time (flow)Request/issue createdIssue done
Cycle time (flow)Work started (in progress)Issue done

DORA lead time is anchored to code and deploys; the flow metrics are anchored to issues/tickets. Don't conflate them.

What data does it need?

  • commits: sha, committed_at.
  • deployments: environment, status, created_at, and the shipped sha (ideally the full set of commits per deploy).

SQL patterns

Median + p90 lead time by week (tip sha)PostgreSQL
SELECT
  date_trunc('week', d.created_at) AS week,
  percentile_cont(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (d.created_at - c.committed_at)) / 3600
  ) AS median_lead_hours,
  percentile_cont(0.9) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (d.created_at - c.committed_at)) / 3600
  ) AS p90_lead_hours
FROM deployments d
JOIN commits c ON c.sha = d.sha
WHERE d.environment = 'production'
  AND d.status = 'success'
GROUP BY 1
ORDER BY 1;
Across all commits in each deploy (more accurate)PostgreSQL
-- Every commit included in a deploy, not just the tip sha
SELECT
  date_trunc('week', d.created_at) AS week,
  percentile_cont(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (d.created_at - c.committed_at)) / 3600
  ) AS median_lead_hours
FROM deployments d
JOIN deployment_commits dc ON dc.deployment_id = d.id
JOIN commits c            ON c.sha = dc.sha
WHERE d.environment = 'production'
  AND d.status = 'success'
GROUP BY 1
ORDER BY 1;

Pitfalls

Measuring merge → deploy only.→ Lead time for changes starts at the commit, not the merge — review and CI are part of it.
Using only the deploy's tip commit.→ A deploy ships many commits; join the full commit set where you can.
Reporting the average.→ Use median and p90; the long tail skews the mean.
Confusing it with flow lead time.→ DORA lead time is commit→deploy, not issue created→done.

Where this metric applies

Metrics

DORA metrics overviewDeployment frequencyChange failure rateTime to restore (MTTR)

Integrations

GitHub + MetabaseGitLab + Metabase

Dashboards

Software delivery dashboard

FAQ

Is lead time for changes the same as cycle time?
No. Cycle time is a flow metric on issues (work started → done). Lead time for changes is a DORA metric on code (commit → production deploy). See cycle time.
Where do I get the commit-to-deploy mapping?
From the deploy record's commit SHA (and, ideally, the list of commits between the previous and current deploy). GitHub Deployments/Actions and GitLab pipelines expose this.
Median or mean?
Median, plus p90 to expose the slow tail. Means are distorted by a few very slow changes.