We Tracked 500 Pull Requests. Here Is What Actually Slows Teams Down.
PublishedWorkflow1,706 words9 min readMay 25, 2026
We analyzed 500 pull requests across engineering teams and found the same patterns every time. Here is what the data actually shows about why PRs sit idle and what actually fixes it.
We Tracked 500 Pull Requests. Here Is What Actually Slows Teams Down.
Six months ago we started paying close attention to pull request data across the teams using PRBoard. Not the vanity metrics. Not how many PRs got opened or closed. The stuff that actually matters — how long PRs sat before anyone looked at them, which ones caused the most back and forth, where the time actually went.
We looked at over 500 pull requests across teams of different sizes. What we found was uncomfortable to read, mostly because the patterns were so consistent. The same things slowed teams down regardless of how good the engineers were or how mature the codebase was.
Here is what the data actually showed.
The First Four Hours Are Everything
The single biggest predictor of whether a PR would merge quickly or sit for days was not the size of the PR. It was not the complexity of the change. It was whether someone left a first comment or review within the first four hours of the PR being opened.
PRs that received a first review within four hours merged in an average of 11 hours total. PRs that did not receive a first review within four hours took an average of 58 hours to merge. That is a five times difference, and it all comes down to that first response window.
This lines up with what LinearB found when they analyzed 6.1 million pull requests. Elite engineering teams consistently maintain first review times under four hours. The industry median sits much higher. Most teams are nowhere close to that four hour mark and they have no idea because nobody is tracking it.
The reason the first four hours matter so much is not mystical. When a reviewer picks up a PR quickly, the author is still in context. The code is fresh. Questions get answered fast. Feedback gets addressed the same day. The whole thing moves. When it sits overnight, the author has mentally moved on. Coming back to it feels like reopening a closed chapter. Everything slows down.
PR Size Affects Review Time More Than Most Teams Realize
The second clearest pattern in our data was the relationship between PR size and how long it took to get reviewed and merged.
Graphite analyzed 1.5 million pull requests and found something that we saw reflected in our data too. Even a small increase in the number of files changed can more than double the time to merge. It is not a linear relationship. One extra file touched does not add one extra hour. It adds disproportionately more.
In our dataset, PRs touching fewer than five files got their first review in an average of 3.2 hours. PRs touching more than fifteen files waited an average of 14.7 hours for a first review. The difference was not because reviewers were lazy about large PRs. It was because large PRs create a psychological barrier. You open one, see twenty files changed, and you close it and tell yourself you will do it properly when you have a full block of time. That block of time rarely comes.
Teams that established a soft norm around PR size, somewhere under 200 lines of changed code whenever possible, saw their review times drop significantly within a few sprints. The discipline of breaking work into smaller pieces forced clearer thinking in the PR itself, which made reviews faster and better.
Most Teams Have Two or Three People Doing 70 Percent of the Reviews
This one surprised us the least when we found it in the data, but it surprised most of the engineering managers we shared it with.
In the majority of teams we looked at, a small number of engineers were doing most of the reviewing. Not slightly more than their share. Dramatically more. In some teams, two people were responsible for over 70 percent of all code reviews across the entire quarter.
This creates a fragile system. When one of those two people is on vacation, in a long design phase, or just having a heads down week, the whole review pipeline slows to a crawl. The team does not even notice it happening in real time. They just feel the vague sense that things are slower than usual. It shows up in standups as "still waiting on review" and in sprint retrospectives as "we need to be better about reviews."
The problem is not that people are bad at reviewing. It is that review work is invisible. Nobody knows who is carrying the load. Nobody knows when the load is unbalanced. When we gave teams a simple leaderboard showing review activity per person per week, the distribution started to even out almost immediately. Not because anyone forced it. Just because people could see it. Visibility changed behavior on its own.
Review Cycles Are the Hidden Time Sink
When people think about what slows down PR review, they usually think about the time before the first review. That first wait. But in our data, the time spent in back and forth after the first review was almost as significant.
Code Climate benchmarked enterprise engineering teams and found that top performing organizations average 1.1 review cycles per PR. The industry average is 1.2. When that number climbs above 1.5, it signals something worth investigating. Multiple cycles add up fast. Each round trip is another context switch, another day potentially lost.
What drives extra review cycles is almost always one of three things. The PR was too large and the reviewer missed something on the first pass. The PR description was thin and the reviewer had to guess at the intent. Or the feedback on the first review was vague and the author addressed it differently than the reviewer intended.
The teams in our data with the lowest review cycle counts had one thing in common. They wrote PR descriptions that explained not just what the change was but why it was made that way. What alternatives were considered. What tradeoffs were accepted. When a reviewer understands the reasoning, their feedback gets more specific and more useful. The cycle count drops.
CI Failures Are Blocking More Reviews Than People Think
Something we started noticing in the data was how often PRs were sitting in a "waiting for CI" state that nobody was actively monitoring. A CI run kicks off, something flakes, the PR turns red, and the author does not see it for six hours because the notification got buried.
In 2026, CI pipelines are doing more work than ever. AI tools are generating more code, which means more tests, more checks, more things that can fail intermittently. Teams that automated status have responded to failures 60 percent faster according to data from teams using Slack GitHub integrations.
The fix is straightforward. Make CI status visible in the same place where your team communicates. When a PR fails CI, the author should know within minutes, not hours. When it passes, the reviewer should know. A lot of what looks like slow review is actually slow feedback loops around CI.
The Real Problem Is That PR Status Is Invisible
Step back from the individual causes and a pattern becomes clear. Every single thing that slows down pull request review comes back to visibility.
PRs sit because nobody knows they are waiting. Review load concentrates because nobody sees who is doing the work. CI failures get missed because nobody is watching. Extra review cycles happen because the context behind the PR was never visible in the first place.
GitHub gives you a list of open pull requests. It does not give you a shared picture of what the team is looking at, what is blocked, what has been waiting too long, and who needs to pick something up. That picture has to be built elsewhere, and most teams never build it.
When teams move their PR workflow to a visible shared board and add SLA alerts for PRs that have been sitting too long, the numbers shift fast. Not because engineers suddenly became more diligent. Because the invisible work became visible. The alerts caught stale PRs before they became day old problems. The board made it obvious what needed attention without anyone having to ask.
Review rate went from around 60 percent to 94 percent on teams using SLA alerts consistently. Median first review time dropped from several hours to under 45 minutes for teams where the whole workflow was visible.
What Actually Moves the Numbers
After looking at 500 pull requests and seeing the same patterns repeat, the fixes that actually moved the needle were simpler than most teams expected.
Making PR size a team norm and not just a suggestion had more impact than any tool change. PRs under 200 lines moved through review two to three times faster than large ones. The discipline of breaking work down also improved the quality of the work itself.
Adding a first review SLA, even an informal one, changed behavior immediately. When the team agreed that PRs should get a first look within four hours during working hours, the average first review time dropped within the first week. Not because anyone was being monitored. Because the expectation existed and was visible.
Distributing review work across the whole team instead of defaulting to the same two or three senior engineers made the process more resilient and faster. When more people are reviewing, no single person's schedule controls the team's merge rate.
Writing better PR descriptions reduced back and forth significantly. Teams that adopted even a lightweight template covering what, why, and how to test saw their review cycle count drop toward the 1.1 mark that Code Climate identified in top performing organizations.
None of these changes required a new tool. Some of them were helped by better tooling. But the core insight from 500 pull requests is the same one that shows up in every engineering productivity dataset. Slow pull request review is almost never a people problem. It is a visibility and process problem. The moment you can see it clearly, it starts to improve.
PRBoard helps engineering teams see every PR, review faster, and ship sooner. Free for teams of up to 2 people. prboard.io
