PR cycle time is how long a change takes from its first commit to being merged. It is the one number that tells you how fast work actually moves through your team, and it is almost never slow for the reason people assume.
This guide splits cycle time into the four stages it is made of, shows real numbers from two large open-source repos, and explains which stage to fix first.
What PR cycle time measures
Cycle time starts at the first commit on the branch and ends when the PR merges. Some teams start the clock when the PR is opened instead; that version is usually called time to merge. Both are fine as long as you pick one and keep it.
It is close to, but not the same as, DORA’s change lead time, which DORA defines as the time for a change “to go from committed to version control to deployed in production.” Cycle time stops at merge; lead time continues through your deploy pipeline. If you deploy on merge, they are nearly identical.
The four stages inside it
A single cycle-time number hides where the time goes. Split it into four stages and the problem usually becomes obvious:
| Stage | Starts | Ends | Usually slow because |
|---|---|---|---|
| Coding | First commit | PR ready for review | The change is too big, or the PR sits in draft |
| Pickup | Ready for review | First human review | Nobody owns the review; reviewers are busy |
| Review | First review | Approval | Back-and-forth rounds, unclear expectations |
| Merge | Approval | Merged | Slow CI, merge conflicts, a release freeze |
Pickup time is the one most teams have never measured, and it is very often the biggest. It is pure waiting: nothing about the code changes while the PR sits there. Our guide on how long a PR review should take covers the target for it (one business day, per Google’s guidance).
Real numbers: React and Vite
We ran our free measurement script on the most recent merged PRs of two busy repos on Oct 6, 2026. Times are wall-clock, so nights and weekends count.
| Repo (PRs) | Metric | Median | p75 | p90 |
|---|---|---|---|---|
| facebook/react (100) | Time to first review | 5.4h | 22.1h | 5.2d |
| Time to merge | 40.5h | 8.1d | 13.1d | |
| Cycle time | 37.0h | 7.4d | 13.4d | |
| vitejs/vite (150) | Time to first review | 19.1h | 3.8d | 7.6d |
| Time to merge | 16.6h | 4.0d | 10.4d | |
| Cycle time | 16.9h | 4.0d | 12.1d |
Three things stand out, and they apply to most teams:
- The median looks fine; the tail does not. React’s median first review is about five and a half hours, but one PR in ten waits more than five days. Authors remember the tail. Track p75 or p90, not just the median.
- Commit dates can mislead. React’s median cycle time (37.0h) is shorter than its time to merge (40.5h), which should be impossible. Commits that were rewritten or recreated before merge can carry a date later than the PR itself. If your team rewrites history often, start the clock at PR open.
- Not every PR gets a human review. 30 of Vite’s 150 PRs merged without one (mostly small maintainer fixes). Leave those out of review-time numbers or they flatter the median.
These are public open-source repos with volunteer reviewers across time zones. A product team with an on-call reviewer should beat them on pickup time.
Which stage to fix first
Measure the four stages, then fix the largest one. In practice the order is almost always:
1. Pickup time (waiting for a first review)
It is usually the biggest stage and the cheapest to fix, because it is a process problem, not a code problem. Give every PR a default reviewer (CODEOWNERS or a daily rotation), agree a same-day target, and put an automated first pass on every PR so the author has something to act on in minutes instead of hours.
2. Coding time (PRs that are too big)
Long coding time usually means the PR is doing too much. Big PRs also slow every later stage: they wait longer for pickup and need more review rounds. On React’s last 100 merged PRs, PRs up to 400 changed lines got a first review in a median of 4.5 hours; PRs over 1,000 lines waited a median of 44 hours (only five such PRs, but the direction matches Google’s and SmartBear’s guidance on PR size). See how big a pull request should be.
3. Review time (too many rounds)
If PRs get picked up quickly but take days to approve, look at the number of review rounds. Common causes: the reviewer and author disagree about scope, style comments arrive one round at a time, or the PR description does not say what to look at. A short PR template (what changed, why, how to test, what to review closely) cuts rounds more than any tool.
4. Merge time (approved but not merged)
Approved PRs that sit for hours point to slow CI, flaky tests, or a manual merge step. Turn on auto-merge for approved PRs with green checks, and fix the slowest CI job first.
Mistakes that make cycle time lie
- Counting bot reviews as reviews. A Dependabot or AI review in two minutes is not a human picking the PR up. Measure them separately.
- Averaging. One PR open for a month drags the average for weeks. Use the median plus p75 or p90.
- Counting drafts as waiting. Start pickup time at “ready for review”, not at PR creation, or draft PRs look like neglected ones.
- Using it to rank people. Cycle time measures the system. The moment it is used to compare individuals, people split PRs to game it and the number stops meaning anything.
A simple target
For a product team: median cycle time under two days, p90 under a week, and pickup time the same business day. Measure weekly, fix the largest stage, and measure again. Our GitHub measurement script gives you pickup time, time to merge, cycle time and the split by PR size in one command.