Lead Time to Production in Span

Last updated: October 27, 2026

Lead time for changes (also called lead time to production) measures how long a merged pull request takes from its first commit to the first successful production deployment that shipped it. It is one of the four DORA metrics and Span's end-to-end measure of delivery speed.

Why it matters

Lead time answers "How quickly does a developer's work reach customers in production?" PR cycle time stops at merge. Lead time keeps going until the code is live, so it also shows how long merged code waits for a release, a wait that is often large and overlooked.

How it works

For each merged PR, Span measures from the PR's first commit to the completion time of the earliest successful production deployment that includes it. The time splits into five stages:

Stage	From → To	What it captures
Coding	First commit → PR opened	Writing code before asking for review
Awaiting first review	PR opened → first review or comment	Waiting for a reviewer to engage
Reworking	First review → last commit or review action	Addressing feedback and iterating
Idling	Last action → merge	Waiting between the final action and the merge
Deploying	Merge → first successful production deployment that includes the PR	Merged code waiting to go live

Lead time for changes = PR cycle time (first commit → merge) + Deploying (merge → in production)

Aggregation: trimmed average (each PR capped at 30 days so outliers don't distort it), P50, P75, P90, or max.
Dating: Span places each PR on its merge date, not its deploy date.
Weekends: if your organization excludes weekends from durations in Settings → Metrics, lead time excludes them too.
Production deployments only: a deployment counts when its status is success and its environment is blank or contains "prod" or "prd", in any letter case. production, PRD-us-east-1, and pre-prod all count. staging, dev, test, and qa don't.

How Span links PRs to deployments. Span turns on deploy-to-PR linking for your organization on request. Once it's on, Span links each successful deployment to PRs in one of two ways:

Explicit: the deployment lists PR numbers in pullRequests. Span uses that list.
Inferred: the deployment lists no PRs. Span takes every PR merged to the repository's default branch after the previous deployment to the same repository and environment, up to the PR whose merge commit matches the deployment's git.refName. If no merge commit matches, the window ends at the deployment's trigger time.

Where to find it. Go to Insights → Productivity → DORA and open Lead time for changes. Filter by date range, team, service, or repository, and switch between aggregations. You can also pin the metric to a custom dashboard. The DORA page version has no per-person breakdown. For a person view and the full stage breakdown, use Insights → Productivity → Velocity → PR lifecycle; the Deploying stage there is something Span turns on for your organization on request.

Why you may see "Time from First Commit to Merge" instead

Until Span turns on deploy-to-PR linking for your organization, the lead time slot on the DORA page shows PR cycle time (first commit to merge). It switches to Lead time for changes once linking is on. Deployments alone don't make the switch; ask your Span account team to turn on linking.

Setup

Connect your git provider so Span has your commits, PRs, and merges. Deploy-to-PR linking works only for repositories on GitHub (github.com), GitHub Enterprise Cloud (*.ghe.com), or Azure DevOps (dev.azure.com).
Send production deployments to Span. Add a step to your pipeline that calls the DORA API (POST /api/dora/v1/deployments) with a service account token. Span doesn't read deployments from your CI on its own.
Ask Span to turn on deploy-to-PR linking for your organization.
Check the DORA page for Lead time for changes.

Fields that matter for lead time:

Field	Required	What to send
`title`	Yes	A descriptive name for the deployment
`triggeredAt`	Yes	When the deployment started, as a UTC timestamp ending in `Z`
`status`	No, but send it	`success`, `failure`, or `pending`. Defaults to `pending`, which never counts
`completedAt`	No	When the deployment finished. Lead time ends at deployment completion
`environment`	No	For example `production` or `staging`. Leave it out for production
`type`	No	`deploy`, `rollback`, or `restart`. Defaults to `deploy`
`git.repoUrl`	No	The repository URL, such as `https://github.com/acme/billing-api`
`git.refName`	No	The full 40-character commit SHA you deployed
`pullRequests`	No	PR numbers in this deployment. Useful for monorepos or partial deploys
`services`	No	Span service slugs, used for team ownership

Team ownership. With deploy-to-PR linking off, Span credits deployments to the teams that own their services. With it on, Span credits the teams of the linked PRs' authors. A deployment Span can't place (no linked PRs, or authors who aren't on a team) counts in your organization total only. Expect team numbers to shift when linking is turned on.

Processing time. A deployment appears in Catalog → Deployments as soon as the API call succeeds. PR linking and lead time are calculated in the background, so expect them on the DORA page within about 3 hours.

Things to know

Worked example. A PR's first commit is Monday 09:00. It merges Tuesday 15:00, and the first production deployment that includes it completes Wednesday 11:00. PR cycle time is 30 hours, Deploying is 20 hours, and lead time is 50 hours. The PR counts on Tuesday, its merge date.
PRs without a production deployment have no lead time. A team that deploys rarely shows lead time only for PRs already shipped.
Send the full commit SHA. Inferred linking matches git.refName against PR merge commits. A short SHA, branch, or tag won't match, so the window falls back to the deployment's trigger time.
Inferred linking assumes you deploy the tip of the default branch. If you deploy an older build, Span can credit PRs to the wrong deployment. PRs merged to other branches are only linked when you list them in pullRequests.
pullRequests needs a matching repository URL. Send a GitHub (github.com or *.ghe.com) or Azure DevOps git.repoUrl for a repository Span already syncs. Other URLs return a 400 error when you send pullRequests.
Span uses commit author dates. Rebases and cherry-picks keep the original dates, which can make Coding look longer.
Span uses deployment completion, not start. Tools that end at deploy start show a shorter lead time.

Using lead time well.

Diagnose by stage. Long Coding often means PRs are too large. Long Awaiting first review points to review capacity or unclear ownership. Long Reworking suggests unclear standards or weak PR descriptions. Long Idling points to CI delays or required approvals. Long Deploying points to manual release steps or release gates.
Look past the average. A healthy P50 with a high P90 means most work flows but some PRs, such as large refactors or cross-team work, get stuck.
Read it with quality metrics. Track Change failure rate, Mean time to recover, and revert rate alongside lead time.
Compare like with like. Bug fixes move faster than architectural changes. Track each team's direction over time.

DORA's research bands for lead time: