Why Pull Requests Sit Too Long (And How to Fix It)

A pull request that sits for days isn't just an annoyance. It's a signal that something in your review process, team capacity, or priorities is off, and it quietly costs you velocity and morale. Engineering leaders often treat a slow-moving PR as an isolated case of bad timing or a distracted reviewer, but when it happens repeatedly, it's telling you something structural about how work actually flows through your team. This article looks at why pull requests sit too long, what that delay actually costs beyond the obvious, and what changes make review cycles faster without turning code review into a rubber stamp.

What Counts as "Too Long" for a Pull Request

Two metrics matter here, and they measure different failure points. Time-to-first-review is how long a PR waits before anyone leaves a comment or approval. Time-to-merge is the total span from opening the PR to it landing in the main branch. A PR can stall at either point: a reviewer might glance at it quickly but the author takes days to address feedback, or the PR might sit untouched for a week before anyone looks at it at all. Tracking only one of these hides half the problem.

As of 2026, many teams aim for a first review within 24 hours and a full merge within two to three business days for a typical-sized change. Treat that as a general reference point rather than a rule, since it shifts with team size, time zone spread, and how complex the average PR is. A five-person team working in one time zone can reasonably move faster than a distributed team of thirty. The point isn't to hit an external benchmark; it's to know your own team's normal cycle time well enough to notice when it drifts.

It's also worth separating a stalled PR from a slow one. A PR with no comments, no reviewer assigned, and no activity for three days is stalled: it has fallen out of anyone's active attention. A PR that's been open for three days but has an ongoing back-and-forth in the comments, with the author and reviewer actively working through design questions, is slow but healthy. The second case might even be a sign of the review process working as intended on a genuinely tricky change. Conflating the two leads teams to either panic over normal architectural debate or ignore PRs that have quietly gone silent. Measuring time-to-first-review and time-to-merge separately, and checking for activity gaps rather than just elapsed time, gives you a much more honest read on where the process actually breaks down.

The Real Reasons PRs Stall

Most stalled PRs trace back to one of a small number of root causes, and none of them are about individual laziness.

The most common is reviewer bottleneck. On a lot of teams, one or two senior engineers become the default reviewers for anything touching core services or unfamiliar territory. Everyone trusts their judgment, so everyone routes PRs to them, and their queue grows until review turns into whatever's left over after their own coding work. This isn't a discipline problem on their part; it's a structural one, where the team has (often unintentionally) centralized a shared resource.

Unclear ownership causes a similar effect from a different angle. When a PR touches a service or module that isn't clearly "owned" by anyone, nobody feels an obligation to pick it up. It sits in a shared queue that technically belongs to everyone and therefore, in practice, belongs to no one.

PR size is its own problem. A 900-line diff touching six files takes real, uninterrupted time to review properly, and reviewers will often deprioritize it in favor of a five-minute PR they can knock out between meetings. The large PR doesn't get rejected or ignored outright, it just keeps losing to easier tasks, day after day, until a week has passed.

Finally, there's the context-switching cost that's easy to underestimate. Reviewing code you didn't write, especially in a part of the codebase you don't touch often, requires rebuilding mental context from scratch: what this service does, why it's structured this way, what the edge cases are. That's real cognitive overhead, and it's exactly the kind of task people put off when they're mid-flow on their own work. The delay isn't reluctance to help; it's the very real cost of switching contexts, multiplied by how unfamiliar the code is.

Why Stalled PRs Cost More Than They Seem To

The visible cost of a stalled PR is the delay itself, but the compounding costs are what actually hurt a team's throughput.

The most mechanical cost is merge conflict growth. The longer a branch lives without merging, the more the main branch diverges from it, and the more likely the author has to spend time rebasing or resolving conflicts before the PR can even be reviewed again. A PR that would have merged cleanly on day one can require a genuinely painful rebase by day five, especially in an active codebase with multiple contributors touching adjacent files. That rework is pure overhead: it adds no value, it's just the tax of waiting.

Stalled PRs also change your deployment risk profile. When reviews are slow, changes don't ship individually and continuously, they pile up and get batched into fewer, larger releases. A release that bundles ten small changes carries more risk than ten releases of one change each, because a bug is harder to isolate and rolling back means rolling back everything, not just the one change that caused the problem. This is the mechanism behind what's often called change-pressure: the cumulative volume and churn of code waiting to ship, which rises whenever review throughput falls behind commit volume.

The least visible cost is what happens to the engineer who's waiting. Rather than sit idle, they reasonably start a new task while their PR is in limbo. That's a sensible individual choice, but multiplied across a team, it means people are perpetually juggling two or three half-finished pieces of work instead of finishing one and moving to the next. Over weeks, this fragments focus, increases the number of things everyone has to mentally track, and shows up as a subtle but real drag on morale. Nobody feels particularly productive when everything they touch is "almost done."

Common Mistakes Teams Make Trying to Fix This

When PR delays become visible enough to bother leadership, the instinct is often to fix the symptom directly, and that usually backfires.

The most common overcorrection is imposing a hard SLA, something like "every PR must be reviewed within four hours." Without addressing why reviews are slow in the first place, reviewers under this pressure tend to rush. They approve changes faster, but the quality of the review drops: fewer questions asked, less scrutiny of edge cases, more bugs that surface later in QA or production. You've traded a visible delay for an invisible quality loss, which is a worse trade.

Adding more required reviewers per PR is another common instinct, on the theory that more eyes catch more problems and spread the load. In practice it usually slows things down further. Now a PR needs two or three people to find time instead of one, and it's stuck until the slowest of them gets to it. Coordination overhead grows faster than review quality does.

The third mistake is treating this purely as a tooling problem: adding a Slack bot that pings people about open PRs, or a dashboard that lists stale reviews. Reminders can help at the margins, but they don't fix a reviewer bottleneck or an ownership gap. If the same one or two engineers are still the only people anyone trusts to review a service, a bot nagging them daily just adds noise on top of an already overloaded queue. The underlying issue is almost always about prioritization (is review treated as real work, scheduled and protected, or as an interruption) and ownership (does everyone know who's responsible for reviewing what). Tools can make the problem visible, but they can't substitute for a team actually deciding that review is a first-class part of the workflow.

Practical Fixes That Actually Reduce Review Time

The fixes that work tend to change the shape of the work or the shape of the schedule, not just add pressure or process on top of the existing setup.

• Cap PR size as a team norm. Encourage diffs under a few hundred lines wherever the change allows it. Smaller PRs get reviewed in minutes rather than deferred to "later," and they're easier to reason about, which improves review quality as a side effect.
• Rotate review ownership explicitly. Instead of defaulting to whichever senior engineer knows the code best, set up a rotation or a clear mapping of who reviews what, by service or by day. This spreads load and forces broader familiarity with the codebase, which reduces the context-switching cost over time since more people stay warm on more parts of the system.
• Make review a scheduled part of the day. A dedicated review block each morning, before new coding work starts, treats review as real work rather than something squeezed into gaps. Teams that do this consistently tend to see review turnaround measured in hours rather than days, without needing a formal SLA to force it.
• Surface stalled PRs automatically. Relying on someone to notice a quiet PR doesn't scale. Automated visibility into which PRs have gone silent, and for how long, turns a fuzzy sense that "reviews feel slow lately" into a concrete, actionable list.

None of these fixes require sacrificing code quality. If anything, smaller diffs and dedicated review time tend to produce more thorough reviews, not less, because reviewers aren't rushing or context-switching mid-task to get to them.

Spotting Stalled PRs Before They Become a Pattern

Manual tracking works fine for a five-person team. Someone glances at the open PR list, notices one has been sitting for four days, and pings the reviewer in Slack. That approach breaks down almost immediately past a certain size. Once you have a dozen engineers and multiple repos, nobody has a full view of every open PR, and the pattern (a particular reviewer always overloaded, a particular service always neglected) only becomes obvious after it's already delayed a release.

This is the gap Progress is built to close. Progress ingests GitHub activity alongside Linear work items and continuously analyzes both, so it can flag stalled PRs and rising change-pressure automatically rather than waiting for a person to notice. Instead of a lead manually cross-referencing PR age against reviewer workload, Progress surfaces that as a pre-computed signal: which PRs have gone quiet, how merge volume and code churn are trending, and where deployment risk is building because changes are bunching up. That means a team lead can catch the bottleneck while there's still time to redistribute review load, rather than discovering it when a sprint slips.

What makes this more useful than a simple stale-PR report is the connection to broader team signals. Because Progress also tracks team momentum and morale, a spike in stalled PRs doesn't have to be treated as an isolated process hiccup. If review delays are climbing at the same time momentum is slowing or morale indicators are dipping, that's a pattern worth investigating as one underlying issue, whether it's overload on a key reviewer, unclear ownership after a reorg, or a team quietly heading toward burnout. Progress can also generate an executive summary or answer a plain-language question about what's happening, through its Claude integration and MCP server, so a CTO can ask "why are PRs taking longer to merge this month" and get an answer grounded in actual GitHub and Linear activity, not a hunch.

Making Review Time a Visible, Managed Metric

Stalled pull requests are usually a symptom of process or capacity issues rather than a discipline problem: a reviewer bottleneck, unclear ownership, or diffs too large to review quickly. Treating the delay itself as the thing to punish, with hard SLAs or extra required reviewers, tends to make the underlying problem worse, not better. The teams that keep review cycles fast are the ones that make review time visible, distribute it deliberately, and catch the pattern early rather than after it's already cost a release.

If you're not sure whether your team's PR delays are a one-off or a pattern worth addressing, that uncertainty is itself worth resolving before it shows up in a missed deadline. Learn more about our services to see how automated visibility into stalled work and team momentum can help you catch it early.