TempoBreak the total into actionable stages
A single cycle-time number cannot tell you why work is slow. Tempo calculates stage-level metrics from pull-request and review events.
- Draft time: time spent before the pull request becomes ready for review.
- Pickup time: time from ready-for-review to the first review.
- Review time: time from the first review until merge or closure.
- Deploy time: time from merge until the linked production deployment.
Use p50 and p90 together
The median, or p50, describes a typical completed pull request. The p90 shows the slower tail—the point below which 90 percent of measured pull requests fall.
A stable p50 with a rising p90 means most work is moving normally while a smaller group is getting stuck. Tempo excludes bot-authored pull requests from these time percentiles so automation does not distort the human workflow signal.
How no-review pull requests are handled
For a completed pull request with no recorded review, Tempo sets review time to zero and assigns the non-draft portion of cycle time to pickup. This keeps the stage totals internally consistent while making no-review work visible as its own flag.
Use cycle time to improve the system
Start with the stage that changed. Rising pickup time points to review capacity or ownership; rising review time can indicate large changes, rework, or unclear expectations. Use repository and pull-request detail to test the explanation before changing process.
- Review p50 and p90 by repository and time window.
- Inspect long-lived, blocked, large, and no-review pull requests.
- Compare AI-assisted and manual work with similar context.
- Treat thresholds as investigation prompts, not performance targets.
Worked PR cycle time example
Consider a pull request created at 09:00, marked ready at 11:00, reviewed at 14:00, and merged at 18:00. Its completed PR cycle time is nine hours. The stage breakdown explains where those hours went.
Deploy time begins after merge and is tracked separately so teams can distinguish code-review flow from release flow.
| Stage | Calculation | Elapsed time |
|---|---|---|
| Draft time | 09:00 → 11:00 | 2 hours |
| Pickup time | 11:00 → 14:00 | 3 hours |
| Review time | 14:00 → 18:00 | 4 hours |
| PR cycle time | 09:00 → 18:00 | 9 hours |
Diagnose the stage before changing the process
The same total cycle time can come from very different systems. Use stage trends and pull-request detail to test the likely cause before adding a policy or target.
| Observed signal | Possible explanation | Question to investigate |
|---|---|---|
| Pickup time rising | Review ownership or capacity is unclear | Are ready PRs reaching the right reviewers quickly? |
| Review time rising | Large batches, rework, or unclear expectations | Did PR size or review rounds change at the same time? |
| p50 stable, p90 rising | A minority of work is becoming stuck | Which repositories or work types contain the slow tail? |
| Cycle time falling, no-review rate rising | Work may be bypassing the intended control | Did speed improve without reducing review quality? |
Frequently asked questions
What is PR cycle time?
PR cycle time is the elapsed time from pull-request creation until merge or closure. Stage metrics such as draft, pickup, and review time explain where the total was spent.
Is PR cycle time the same as lead time for changes?
No. PR cycle time covers the pull-request lifecycle. Lead time for changes usually extends from a code change or commit until it runs successfully in production, so it can include time before PR creation and after merge.
Should teams use average or median PR cycle time?
The median is more resistant to extreme outliers and describes typical work better. Pair p50 with p90 so improvements to the typical case do not hide a growing slow tail.
What is a good PR cycle time?
There is no universal target. Compare similar repositories and work types, establish a baseline, and improve the stage that creates avoidable waiting while watching quality and review signals.
Sources and further reading
- DORA guide to lead time for changesContext for the broader delivery metric that extends through production.
- GitHub documentation for reviewing pull requestsThe review events and workflow concepts behind pull-request stage measurement.