Why Pull Requests Sit for Days Between Reviews

A pull request I watched sit for close to a month wasn't unusual because of what kind of change it was. I've seen this happen to a two-line fix as often as a full rewrite. What was unusual, looking back, was how little of that month was actually spent doing anything to it.

Sometimes it was the author — pulled onto something else, and the PR just stopped existing in their head until someone pinged them again. Other times it went the other way: a reviewer left a real comment, got a real answer back — not two words, an actual explanation of why the suggestion wouldn't work — and never saw it land. The thread just sat there. The author considered it closed. Nobody else looking at the PR had any way to know that. At least once, a build had been failing for days on a PR whose author genuinely hadn't noticed.

Someone on r/agile put a version of this better than I could: the three days a PR takes has almost nothing to do with three days of review work. Nobody spends three days reading a diff. The diff gets read in twenty minutes, and then the PR waits — for someone to notice it, reply to it, or remember it exists.

Who owns the next move on a pull request is the first half of this. Once you know whose move it is, the next question is how long it actually takes them to make it, and where that time goes.

Lay one of these out as a timeline instead of a status and the shape repeats — no single PR looked exactly like this, but the pattern below is close to true of several. The reviewer opens the diff Tuesday morning — fifteen minutes, maybe twenty — and leaves four comments. The author doesn't see them until Wednesday, clears three by lunch, and writes a real reply to the fourth explaining why it won't work. The reviewer doesn't open the PR again until the following Monday — a weekend in between, and nothing told them a reply was sitting there. By the time they read it, agree, and approve, six calendar days have passed for something closer to forty-five minutes of anyone actually looking at code.

This is usually filed under cycle time — the split between active work and queue time that flow-efficiency thinking borrows from manufacturing. In a factory, queue time is a part sitting on a shelf: genuinely idle, nobody's fault, just capacity waiting to free up. A pull request's queue time mostly isn't that. The six days above went to a reply nobody reopened the tab to see. The build that sat red for days, from earlier, is the same shape — nobody was waiting on capacity, just on someone happening to look. That's a narrower problem than a queue being long, and reviewer capacity isn't what fixes it.

I have more than that one walkthrough, too. Since the tool that tracks all this is the one I built, I pulled the real numbers off my own board — the last six months or so, a few dozen PRs, a narrower slice than the story above: just the ones I've reviewed rather than authored, not the full round trip. Before I even open one I'm needed on, the median wait is about thirty hours, and past five days for the slowest quarter of cases. Once I've actually left something, a comment or a review, the median wait before anyone touches the PR again is about fifteen hours, and close to three days for the slowest quarter of cases.

The part that's shifted recently, at least on the team I watch most closely, is the ratio between the two. AI took a real chunk out of the active-work side — the writing, and a good share of the reviewing too, since a careful read is increasingly closer to checking an AI's read than starting from nothing. The waiting side didn't shrink to match. Some weeks it feels like double the elapsed time against the real work, other weeks more than that. That's a felt sense from watching a board, not something I've measured, but it fits the general shape of what cheaper generation does. Review itself isn't any faster. The gap between the actual work and how long a PR sits has only gotten wider.

PR Flow's queue is built around that gap rather than the diff itself. A thread with a reply nobody's looked at yet shows up as unresolved, not as a comment that's been dealt with. A PR whose CI just went red moves straight back into the author's list the moment it happens, whether or not they've thought to check that tab. Age shows up as a visible border, so a PR that's been open a month looks different from one that opened an hour ago at a glance.

None of that shortens the twenty minutes it takes to read a diff. An overloaded reviewer is still overloaded. A team that's quietly deprioritized review keeps deprioritizing it, whatever the board shows. What changes is smaller: the fifteen hours a reply usually waits before anyone looks again — or the three days it stretches to when it's slow — stops being invisible. Whether that's enough to matter on its own, I'm honestly not sure it's the same answer for every team.