PR Pickup Time: The Metric Nobody Watches
NOBODY WATCHES THIS ONE
Most 'slow review' is a PR sitting untouched, waiting for a first look. Why pickup time is the highest-leverage review metric - and the cheapest to fix.
Review - 46% of every cycle.
Illustrative example
TL;DR: Pickup time - how long a PR waits between "ready for review" and a reviewer's first action - is where most "slow review" actually lives. LinearB's 2026 benchmarks put elite teams under an hour; past 16 hours you're in the "needs focus" band. It's also the cheapest metric in your pipeline to improve: nobody has to review faster or read less carefully. Someone just has to start.
Teams instrument everything about review except the part where nothing happens. Review depth, comment counts, approval rules - all watched. Meanwhile the PR spends two days untouched before any of that begins, and the retro concludes "reviews are slow." They aren't. They're late.
What is PR pickup time?
Pickup time is the interval between a pull request becoming ready for review and a reviewer taking the first action on it: a comment, a requested change, an approval. It measures the waiting, the queue before the work rather than the work itself. It is consistently where the largest, least-examined share of review delay hides.
It hides well because no one owns it. The author "did their part" by opening the PR. The reviewer "will get to it." Between those two sentences, days pass. In everyone's memory, that elapsed time gets filed under "review," slandering the twenty minutes of actual reading that eventually happened.
What is a good PR pickup time?
LinearB's 2026 engineering benchmarks, built from 8.1 million+ pull requests across 4,800 teams, give the clearest published bands:
| Band | Pickup time |
|---|---|
| Elite | under 1 hour |
| Good | 1-4 hours |
| Fair | 5-16 hours |
| Needs focus | over 16 hours |
For a second reference point: in Google's study of 9 million reviewed changes, authors wait a median of under an hour for initial feedback on small changes, and about 5 hours even for very large ones. Waiting a day for a first look isn't normal-with-extra-steps. By every published bar, it's an outlier.
Pickup time is pure waste with compound interest
And cutting it costs nothing. The 2023 DORA report found teams with faster code reviews show 50% higher software delivery performance, and pickup is the review stage you can accelerate without touching quality. Shortening the reading risks shallower reviews; shortening the waiting risks nothing.
Meanwhile the waiting quietly bills you:
- Context decays. The author who could answer any question about the diff on Tuesday is three tasks away by Thursday. Every review comment now costs a mental round-trip.
- The diff ages. Main moves, conflicts accumulate, the rebase tax grows. Long-waiting PRs drift toward stuck-PR territory, and some never come back.
- Everything downstream inherits the delay. Pickup sits at the front of the review pipeline; days lost there are unrecoverable by any amount of fast reviewing later. In a cycle-time anatomy, it's routinely the widest slice - and the one nobody was looking at.
How do you reduce PR pickup time?
This is a habit change rather than a process overhaul, which is exactly why it's the cheapest win in your pipeline:
- Make the queue visible. A PR waiting in a list nobody looks at is invisible. Waiting-for-first-review should be impossible to not see: surfaced where the team already lives, with its age attached.
- Agree on a window. A working agreement - "first response within four working hours" - turns pickup from a favor into a norm. The number matters less than its existence: it converts "someone should look" into "this is late."
- Name a reviewer. Requests aimed at a person get picked up; requests aimed at a team get admired. Google's median change has one approver; one clearly responsible reader beats a CC line every time.
- Sweep at natural breaks. Reviewers don't need to drop everything; they need two or three queue sweeps a day. After standup, after lunch, end of day. Predictable beats instant, and it protects maker time.
- Keep PRs pickable. A 150-line PR is a coffee-break decision; a 1,500-line PR is an afternoon someone has to find. Small PRs get started sooner because starting them costs less courage.
Watch one number for a month: how long PRs wait for their first review action. It's the highest-leverage metric in your review pipeline precisely because nobody has been watching it. The fix requires no new tools, no new roles, and no one reviewing a line less carefully. The queue just has to move.
Frequently asked
What is a good PR pickup time?
LinearB's 2026 benchmarks (8.1 million+ PRs across 4,800 teams) put elite pickup time under 1 hour, good at 1-4 hours, fair at 5-16, and over 16 hours as 'needs focus.' A useful team bar: every PR gets its first look within a few working hours, same day at worst.
Is a pickup time of zero the goal?
No. Instant, interrupt-driven review would shred everyone's focus: you'd be trading the author's wait for the reviewer's fragmentation. The goal is a short, predictable window: reviewers sweep the queue at natural breaks, and authors know a first look lands within hours, not 'whenever.'
How is pickup time different from review time?
Pickup time is the wait before anything happens: ready-for-review until the first reviewer action. Review time is the work after that first action: reading, comments, revisions. They fail differently: long pickup is a queue and habit problem; long review is a size, complexity, or depth problem.
How do you handle pickup time across time zones?
Measure it in working hours, not wall-clock hours, or your night is every metric's rush hour. Then design for the overlap you do have: route reviews to people whose day is starting, not ending, and treat the overlap window as review time first. Distributed teams don't get a pass on pickup; they need the routing to be deliberate.