Pull Request Stuck in Review? A Triage Guide
BLOCKED, OR RADIOACTIVE?
A PR stuck in review is blocked, abandoned, or radioactive - three different problems. How to tell which you have, and unstick each without a guilt trip.
TL;DR: A pull request stuck in review is one of three different patients: blocked (nobody ever picked it up), abandoned (review happened, the author moved on), or radioactive (everyone opened it, winced, and fled). They look identical in the PR list and need opposite treatments. Diagnose first, then unblock the queue, make the close-or-finish call, or split the monster.
Every team has one right now: the PR that's been "in review" for eleven days. It comes up in standup, someone says "I'll look today," and the ritual repeats on Thursday. Before you escalate, diagnose. The three ways a PR gets stuck have three different fixes, and applying the wrong one makes it worse.
Why do pull requests get stuck in review?
Because "in review" is a status, not an activity. For calibration: Google's study of 9 million reviewed changes found the median time for the entire review process is under 4 hours. A PR that's been open for a week isn't experiencing slow review; it's experiencing no review, and the label hides which kind of nothing is happening:
- Blocked - the PR is fine; the queue is broken. No reviewer has taken a first look.
- Abandoned - the review worked; the author didn't come back to the feedback.
- Radioactive - reviewers are actively avoiding it because it's too big, too risky, or too tangled to face.
Is your PR blocked, abandoned, or radioactive?
Check the timeline, not the vibes:
| Signal | Blocked | Abandoned | Radioactive |
|---|---|---|---|
| Reviewer activity | None since opened | Comments left, then silence | Opened, skimmed, one comment, fled |
| Author activity | Waiting, maybe nudging | Moved to other work; comments unanswered | Still pushing commits into the void |
| Diff size | Any | Any | Large: hundreds to thousands of lines |
| What people say | "I didn't see it" | "Oh right, that one" | "I'll get to it" (third time) |
The distinction matters because the failure is in a different seat each time: blocked is a team habit failure, abandoned is a prioritization failure, radioactive is a change design failure. None of them is fixed by asking harder.
Unsticking a blocked PR
A blocked PR is a pickup problem, and pickup is the cheapest review metric to fix: nobody has to review faster, someone just has to start. LinearB's 2026 benchmarks (8.1 million+ PRs) rate pickup time over 16 hours as "needs focus"; elite teams start in under an hour.
For this PR: one direct, scoped ask to one named person. For the pattern: make the waiting queue visible and agree on a first-response window, so unblocking stops depending on who nags best.
Unsticking a radioactive PR
You don't push a radioactive PR through review. You shrink it until it stops being scary. SmartBear's Cisco study found reviewers are effective on 200-400 lines at a time, with 70-90% defect discovery in that band. Your 1,800-line PR is not going to get that review. Ever. Options, in order of preference:
- Split it. Carve out the mechanical parts (renames, moves, formatting) into their own small, quickly-approvable PRs. What remains is the real change, at reviewable size.
- Guide the reader. If splitting is genuinely impossible, write the tour: where to start, what changed and why, which files are consequential and which are noise.
- Review it live. Thirty minutes of synchronous walkthrough beats three weeks of asynchronous dread. The PR is the agenda; the approval happens with both people in the room.
And afterwards, fix the factory. Radioactive PRs are usually built, not born: scope that grew mid-flight, a refactor tangled into a feature. Smaller PRs prevent the next one.
When should you close a stalled PR?
When nobody will honestly commit to finishing it. An abandoned PR quietly rots: main moves on, conflicts compound, and the eventual rebase costs more than the original work. Ask the author one question - "is this coming back this sprint?" - and believe the answer. If it's no, close it with a note. The branch survives; the queue gets honest; and your review metrics stop being haunted by a ghost from March.
That's not punishment. Punishment is leaving it open so it can die in public for another quarter.
Preventing the next one
The stuck PR you just triaged is a symptom. The system fix is three habits: keep changes small enough to review in one sitting, agree on a pickup window and watch it, and spread review across enough people that one full calendar can't stall the team. The failure modes have early signatures: a PR accumulating commits without approvals, review rounds piling up, a diff that keeps growing after review started. That is exactly the kind of pattern a struggled-PR detector flags while the PR can still be saved, instead of at the retro.
A stuck PR is never a character flaw. It's your process leaving fingerprints - read them, and the next one doesn't get stuck.
Frequently asked
How long is too long for a PR to be in review?
LinearB's 2026 benchmarks call review time over 24 hours 'needs focus'; Google's internal median for the whole review process is under 4 hours. Calendar-days-old PRs are outliers by any published bar. The useful question isn't 'how long is acceptable' but 'which failure mode is this one in.'
Should I ping the reviewer or wait?
Ping - once, directly, naming the specific thing you need: 'Can you take the first pass on this today?' A direct, scoped request gets picked up; a passive re-request or a sad emoji in the team channel gets ignored. If you have to ping on every PR, the problem is your team's pickup habits, not this PR.
Is it OK to just close a stalled pull request?
Yes, and sometimes it's the kindest move available. A branch that's months behind main costs more to resurrect than to rewrite, and the code isn't destroyed: the branch and its history remain. Closing with a note beats letting a zombie PR haunt the queue and skew every review metric you track.
Why do large PRs get stuck more often?
Because nobody can review what they can't hold in their head. SmartBear's Cisco research found reviewers are effective on 200-400 lines at a time, with defect discovery dropping beyond that. A 2,000-line PR doesn't look like work to a reviewer; it looks like an afternoon they don't have. So they open it, wince, and flee.