The Review Queue: Why Pull Requests Spend More Time Waiting Than Being Worked On

Ask an engineering leader why delivery is slower than last year and you will hear about scope, dependencies and estimation. Ask how long a finished pull request waits before anyone opens it, and very few can answer — because nobody owns that time.

The Friction: Finished Work That Nobody Is Looking At

In a team of eight, a pull request waiting for review is visible in the stand-up. In an organization of 1,500 engineers opening 4,500 pull requests a month across hundreds of repositories, the review queue disappears for structural reasons:

• Cycle time hides it. A median cycle time of three days says nothing about whether those days were spent coding, reviewing or waiting. Leadership sees one number and asks teams to "go faster".
• Nobody owns the wait. The author has finished; the reviewer hasn't started. The time in between belongs to no one's sprint, no one's ticket and no one's objectives.
• Review load concentrates. Code owners, staff engineers and the people who know the legacy systems are requested on everything. The queue forms in front of them, not in front of the organization.
• More pull requests, same reviewers. AI coding assistants have made opening pull requests cheaper. Reviewing them has not become cheaper at all.

The result: engineers context-switch to new work while their last pull request waits, work in progress piles up, and the roadmap slips for reasons that never appear in any retrospective.

Why This Matters: The Real Cost of the Review Queue

The Throughput Problem

A pull request waiting for review is finished work producing no value. Every day in the queue is a day the feature isn't in production, the bug isn't fixed and the author's context fades. When the wait doubles, delivery slows even if every engineer works exactly as hard.

The Context-Switching Problem

Engineers don't sit idle while they wait: they start something else. When the review finally arrives, they switch back, reload the context and answer comments on code they wrote days ago. The longer the queue, the more expensive every review round becomes.

The Senior Engineer Problem

The people at the front of the queue are usually the most experienced. Their review load grows silently, eats the time they should spend on architecture and mentoring, and is a frequent and under-reported cause of burnout among staff engineers.

The Enterprise Discussion: What Engineering Leaders Are Actually Saying

Slow code reviews, pull requests "sitting for days" and the review burden on senior engineers are among the most recurring complaints wherever engineering managers, staff engineers and directors at large organizations compare notes. The quotes below are representative of recurring threads on r/ExperiencedDevs, r/EngineeringManagers, r/softwareengineering and r/devops.

The pattern holds: leaders feel that reviews are the bottleneck, but they measure cycle time as a single number — so the wait, and who it lands on, stays invisible.

How Keypup MCP Measures the Review Queue

The Keypup Model Context Protocol (MCP) Server gives your AI assistant structured access to the data Keypup imports from GitHub, GitLab, Bitbucket, Azure DevOps and Jira. For this analysis, what matters is each pull request's first commit date, review request date, first review submission date, last approval date, merge date, requested reviewers, lines changed, target repository and state, plus the reviews dataset: every submitted review with its author, request date and submission date.

In the prompts below, the wait for first review is measured in business hours — Monday to Friday, 09:00 to 17:00 UTC by default — from the review request to the first submitted review. When a pull request has no review request, the clock starts at its creation date. Business hours keep weekends and nights from inflating the numbers; adjust the working hours and time zone to match your teams.

1. Running a Review Queue Health Check

The first question: how long does finished work wait before anyone looks at it?

MCP Prompt:

For pull requests merged in the last 12 months that received at
least one review, show the count, the median and 90th percentile
business hours from review request (or creation when no review
was requested) to first submitted review, the share that waited
more than 16 business hours, and the total wait for first review
as a share of total business hours from creation to merge.

Output: Review Queue Health Check — Last 12 Months

Key Insight: A typical pull request waits a day and a half of working time before anyone looks at it, and one in four waits more than two working days. Waiting for a first review is 41% of all the time between opening a pull request and merging it.

2. Breaking Cycle Time Into Phases

A single cycle time number can't tell you where to act. Splitting it can.

MCP Prompt:

For pull requests merged in the last 12 months, break cycle time
into four phases — first commit to review request, review request
to first review, first review to last approval, last approval to
merge — and show the median business hours of each phase as a
waterfall.

Output: Where Does Cycle Time Actually Go?

Key Insight: The longest phase of the pull request lifecycle is the one where nobody is working on it. Waiting for a first review takes 11.5 business hours — almost twice the coding before the request, and more than every review round combined.

3. Tracking the Queue Month by Month

Is this a bad quarter, or a trend?

MCP Prompt:

By month of merge over the last 12 months, show merged pull
requests as bars, with lines for the median and 90th percentile
business hours from review request to first review.

Output: Is the Queue Getting Longer?

Key Insight: The median wait for a first review grew 78%, from 7.8 to 13.9 business hours, while monthly merges grew 9%. The 90th percentile went from 31 to 54 hours: the slowest pull requests now wait almost seven working days for a first look.

4. Seeing When Review Requests Get Stuck

When a review is requested says a lot about how long it will wait.

MCP Prompt:

As a heatmap, show the median business hours from review request
to first review by weekday and UTC time block of the review
request, for pull requests merged in the last 12 months. Add the
number of requests and the median for each weekday.

Output: When Does a Review Request Get Stuck?

Key Insight: A review requested on Friday afternoon waits 21.4 business hours — three times as long as one requested on Wednesday morning. Even with the weekend excluded, Friday requests join the Monday backlog, which is why Monday mornings are the slowest slots outside Friday. Times are in UTC; for teams spread over several time zones, ask your assistant to split the heatmap by repository or to compute business hours in each team's time zone.

5. Finding Who Carries the Review Load

An organization-wide median hides the people the queue forms in front of.

MCP Prompt:

For reviews submitted in the last 12 months, rank reviewers by
number of reviews submitted and group them into deciles. Show
each decile's share of all reviews as a Pareto chart with the
cumulative share, and the median business hours from review
request to review submission for each decile.

Output: Who Is Actually Carrying the Review Load?

Key Insight: The top 10% of reviewers submit 46% of all reviews, and the top 20% submit 63%. They are also the slowest to respond — 14.8 business hours against about 7 for everyone else. The queue is not a capacity problem across the organization; it is a capacity problem for 118 people.

6. Testing Whether Size Drives the Wait

If reviewers pick the easy pull requests first, large ones should wait longer.

MCP Prompt:

For pull requests merged in the last 12 months, group them by
lines changed — under 50, 50 to 199, 200 to 499, 500 and more —
and plot the median and 90th percentile business hours to first
review for each group, with each group's share of merged pull
requests.

Output: Do Big Pull Requests Wait Longer?

Key Insight: A 500-line pull request waits more than five times as long for a first look as one under 50 lines — 22.8 business hours against 4.2. Reviewers pick small pull requests first, so splitting work is the cheapest way to shorten the queue.

7. Listing the Queue Right Now

The last step turns the analysis into something to act on today: which pull requests are waiting, and for whom?

MCP Prompt:

List open, non-draft pull requests that have no submitted review
and have waited more than 24 business hours since review was
requested or since creation. Show the pull request, repository,
number of reviewers requested, lines changed, business hours
waiting and the issue type of the Jira issue it resolves. Sort
by wait.

Output: The Queue Right Now

Key Insight: Eight pull requests have waited more than three working days for a first look. Two have no reviewer requested at all, so they are waiting for nobody. Two are over 800 lines — the ones nobody wants to pick up — and three resolve Stories that sit on the roadmap.

The Technical Implementation: What Keypup MCP Actually Reads

Every number above comes from fields Keypup already imports from your Git platforms and Jira. It helps to be precise about what they are — and what they aren't.

The Wait Comes From Review Timestamps

For each pull request, Keypup records the review request date, the first review submission date, the last approval date and the merge date, along with the first commit date and creation date. The wait for first review is the time between the first two. If your teams never use the platform's "request review" feature and simply share links in chat, there is no request date: the clock then starts at creation, which includes any time the author was still working on the pull request. Treat that part of the numbers with care until requesting reviews on the platform is the norm.

Business Hours Come From a Formula, Not a Calendar

Keypup's BUSINESS_HOURS function counts working hours between two dates — Monday to Friday, 09:00 to 17:00 UTC by default — and accepts a different time zone, working hours and working days. It does not know about public holidays, vacations or on-call rotations: Keypup does not import calendars.

Review Load Comes From the Reviews Dataset

Every submitted review is a record with its author, the date it was requested (empty for spontaneous reviews) and the date it was submitted, linked to its pull request and repository. The reviewer ranking counts submitted reviews per author; response time uses requested reviews only. Reviews given in a call or a chat thread aren't visible.

Size and Status Come From the Pull Request

Size is the pull request's lines changed, additions plus deletions. The open queue uses the pull request state — draft pull requests have their own state and are excluded — the list of requested reviewers and the absence of a first review date.

Linked Issues Depend on How Pull Requests Reference Jira

Keypup links a pull request to the Jira issues it resolves when the issue key appears in the branch name, title, description or commit messages. The linked issue's type comes from your Jira configuration. A pull request with no key in any of those places shows no linked issue.

Real-World Impact: Enterprise Case Studies

Case Study 1: European Insurance Group

Before Keypup MCP:

• 1,100 engineers across 260 repositories
• A cycle time target missed for three quarters running, blamed on "estimation"
• Code owners requested on every pull request in their repositories

After Keypup MCP:

• The cycle time breakdown showed that waiting for first review was 44% of cycle time, which moved the improvement plan from estimation training to review capacity
• The reviewer Pareto showed 9% of reviewers submitting half of all reviews; code owner rules were narrowed to critical paths and a rotating "review buddy" was added to each team
• The median wait for first review fell from 13 to 6 business hours in two quarters, and cycle time followed

Case Study 2: North American Software Company

Before Keypup MCP:

• 1,600 engineers, 5,000+ merged pull requests a month after an AI assistant rollout
• Cycle time up 35% in a year, with no explanation leadership could agree on
• Staff engineers reporting review fatigue in every engagement survey

After Keypup MCP:

• The monthly trend showed the wait for first review growing four times faster than pull request volume, which made the case for reviewer capacity in the next budget cycle
• The size plot became a team guideline: pull requests above 400 lines need a stated reason, and the share of pull requests above 500 lines fell from 14% to 7%
• Team leads run the open queue prompt every morning and share the list in their team channel, so no pull request waits more than three working days without someone noticing

Implementation: Getting Started with Keypup MCP

1. Connect Your Git Platforms and Jira

Connect GitHub, GitLab, Bitbucket or Azure DevOps, and Jira, to Keypup. Pull requests, their review timestamps, requested reviewers, reviews and linked issues are imported automatically.

2. Make Review Requests Explicit

Ask teams to request reviewers on the platform rather than sharing links in chat. The request date is what starts the clock; without it, the wait can only be measured from creation.

3. Agree on Your Working Hours

Decide which working hours and time zones your business hours should use, team by team if needed, and use them in every prompt so numbers stay comparable.

4. Connect the MCP Server to Your AI Assistant

Follow the MCP documentation to connect Keypup to Claude, ChatGPT, Cursor or any MCP-compatible assistant.

5. Set a Baseline, Then Work the Queue Every Day

Run the health check and the cycle time breakdown to set a baseline. Then check the open queue every morning, review the reviewer load every month, and report the wait for first review next to cycle time — so a slow queue is never mistaken for slow engineers.

Frequently Asked Questions

What is the wait for first review?

It is the time between a pull request being ready for review — usually when a reviewer is requested — and the first review being submitted. It is sometimes called review pickup time. It measures waiting, not reviewing.

How do you measure code review wait time?

Take each pull request's review request date and first review submission date, and compute the business hours between them. Keypup MCP does this with its BUSINESS_HOURS function, which excludes nights and weekends and accepts your own working hours and time zone.

Why do pull requests wait so long for review?

Most often because review load is concentrated on a few people — code owners and senior engineers — because large pull requests get postponed, and because requests made late in the week join the Monday backlog. Measuring the wait by reviewer, by size and by time of request shows which of these applies to you.

What is a good wait for first review?

There is no universal benchmark: it depends on your time zones, team structure and release model. Many teams aim for a first review within one working day. The trend, and the spread between reviewers and repositories, matter more than the absolute value.

The Bottom Line

Cycle time that is mostly queue isn't an engineering speed problem — it's a review capacity problem. Keypup MCP shows how long your finished work waits, and where:

✅ Measuring the wait for first review in business hours, from request to first review ✅ Breaking cycle time into phases to show how much of it is waiting ✅ Tracking the trend of the median and 90th percentile wait month by month ✅ Showing when review requests get stuck, by weekday and time of request ✅ Showing who carries the review load and how fast they can respond ✅ Testing how pull request size affects the wait ✅ Listing the pull requests waiting right now, and for whom

Ready to find out how much of your cycle time is queue? Connect the Keypup MCP Server and ask your AI assistant.