See where pull requests wait, and what the queue holds up

AndonPulse splits review time into stages, shows where the queue forms by repository, team and reviewer, and links each waiting pull request to the work it blocks.

Request free access Book a demo
Pull request review dashboard for August. Median pickup time 1.3 days, median review time 0.6 days, 22 pull requests waiting for review and 317 merged. Charts show review stages by team, the Platform review time trend, the share of first reviews by reviewer and pickup time by repository.

Read-only connections to the tools your teams already use

  • Jira
  • GitHub
  • GitLab
  • Linear
  • Claude Code
  • Cursor
  • Codex
  • BambooHR
All integrations

Everyone says review is slow. Nobody can say where.

Git hosts show pull requests one repository at a time. The review flow across your teams stays out of sight.

The team says
Review is a bit slow
The data shows
22 pull requests wait for review

The queue is invisible

Open pull requests sit across dozens of repositories, and nobody sees the total until a release slips.

The team says
Anyone can review
The data shows
2 people do 61% of first reviews

The same few reviewers

Requests go to the people who know the code best, so a handful of engineers end up reviewing for everyone.

The team says
Cycle time is fine
The data shows
3.7 days of pickup time

One average hides the problem

Cycle time mixes coding, waiting and review, so you can't tell which part of the work got slower.

From a slow review queue to a decision, in five clicks

Median review time in the Platform team over ten weeks, from 2.1 days to 4.8 days.
Pull request review stages by team in August. Platform has 3.7 days of pickup time, 0.8 days of review time and 0.3 days of merge time. The other teams have 0.7 to 1.4 days of pickup time.
Median pickup time by repository in the Platform team. platform-gateway 5.2 days, auth-service 4.4 days, the others 0.6 to 1.4 days.
Share of first reviews by reviewer in Platform repositories in August. Two Platform reviewers did 33% and 28%, the others 8% to 12%.
Median review time in the Platform team over sixteen weeks. It rose from 2.1 to 4.8 days, then fell to 1.8 days in the six weeks after the change.

Spot the trend

Median review time in the Platform team, from opened to merged, went from 2.1 to 4.8 days in ten weeks.

A change in the trend shows up before the sprint review.

Find the stage

Most of the 4.8 days is pickup time: 3.7 days. Review time and merge time are close to the other teams.

Stages come from pull request events and your own statuses.

Open the repositories

Two repositories hold most of the pickup time: platform-gateway at 5.2 days and auth-service at 4.4 days.

Group repositories by team, product or Deliverable.

See the review load

Two Platform reviewers did 61% of first reviews in August. Pull requests waited for them.

A review load problem, not slow engineers.

Check the result

The team made two Payments engineers code owners of platform-gateway and auth-service, and agreed on a daily time for reviews. Six weeks later, median review time was 1.8 days, down from 4.8.

AndonPulse doesn't make the decision. It shows where to act, and then whether the change worked.

Book a demo

What you can do with pull request analytics

Where do pull requests wait?

Today
A feeling that review is slow, and a debate about it in the retro.
With AndonPulse
Pickup time, review time and merge time for every team and repository, with drill-down to the pull requests that waited.

A 40-engineer B2B SaaS team cut median pickup time from 2 working days to 1. Read the story

Pull request review stages by team in August. Platform has 3.7 days of pickup time, 0.8 days of review time and 0.3 days of merge time. The other teams have 0.7 to 1.4 days of pickup time.

Who carries the review load?

Today
Review requests go to the people who know the code best, and nobody sees how much they carry.
With AndonPulse
Each reviewer's share of first reviews, by repository and team, so you see when a few people review for everyone.

In the B2B SaaS story, most of the waiting traced back to a few reviewers who covered several repositories.

Share of first reviews by reviewer in Platform repositories in August. Two Platform reviewers did 33% and 28%, the others 8% to 12%.

Which work does the queue hold up?

Today
A release slips, and only then the team finds the pull requests that waited all week.
With AndonPulse
Each pull request links to its Issue and Deliverable, so a growing review queue shows up as a delivery risk.

The same data feeds cycle time, sprint reports and delivery forecasts, with no second setup.

Pull requests waiting for review by Deliverable. Payments API v2 has 11, SSO for admins 5, the others 1 to 3.

How AndonPulse measures review time

AndonPulse reads the events of every pull request in GitHub or GitLab and splits its time into three stages.

Drafts and bots do not count
Pickup time starts when the pull request is ready for review. A bot comment does not end it, and you choose which accounts are bots.
What it does not tell you
Fast review is not the same as good review. Read review time together with rework and cycle time.
Not a score for people
Reviewer views show how review work is shared. There are no leaderboards and no individual productivity scores.

platform-gateway #1482 · Retry failed webhooks

Pickup time
1 d 19 h
Review time
1 d 3 h
Merge time
19 h 21 min
  1. Opened as a draft Not counted
  2. Marked ready for review
  3. ci-bot posts a coverage report Not a review
  4. First review: changes requested
  5. Approved
  6. Merged

Ready for review to merge: 3 d 18 h. Point at a stage to see where it starts and ends.

One platform. Pull request analytics is one of its views.

Connect your tools once. The same delivery model powers every view.

Engineering delivery

AI analytics

Planning & finance

Initiatives across teams on one timeline.
One Deliverable bar: work done so far, work left at the current pace, the planned date and the forecast.

Every initiative, its forecast, and the work behind it.

Open this view
DORA metrics: deployments by month, change failure rate by month, lead time for changes of 19 hours and time to restore service of 0.7 hours.

Delivery speed and stability, with the deployments and pull requests behind each change.

For each sprint, carryover, newly committed and added work next to completed and added-and-completed work.

Which sprint work is at risk before the review, and why it carried over.

Pull request metrics: time to merge for each pull request, lifetime by stage with 14 hours waiting for the first review, and 219 merged pull requests.

Where reviews wait, and who carries the load.

Share of merged pull requests with AI assistance, by team.

See how much of your work involves AI coding tools, by team.

Cycle Time with and without AI.

Compare Cycle Time for work with and without AI assistance.

Active AI tool users by month.

Follow how AI coding tools spread across teams over time.

AI tool cost next to the value of engineering hours saved.

Put the cost of AI tools next to what they change.

Share of effort by type of work, month by month.

Where engineering capacity goes, compared with the plan.

Capitalizable hours and cost, with engineering hours by category.

Audit-ready R&D reports from measured work.

Open this view

Up and running on your data

No new fields and no timesheets. Our customers saw first results in 2 to 4 weeks.

  1. 5–15 minutesConnect your tools

    GitHub or GitLab, plus Jira or Linear, with read-only access.

  2. Same dayLoad your history

    Past months come in at once, so you have a baseline before you change anything.

  3. With our teamMap repositories and teams

    Teams, repositories and review statuses, checked on your real data.

  4. Weeks 2 to 4See your review flow

    Pickup time, review time and merge time for every team, with the slowest pull requests on top.

  • Separate database for each customer
  • SSL/TLS and encryption of sensitive data
  • Read-only integrations
Trust Center
The math is fully transparent — because we write the rules ourselves in the platform.
Eugene Gusarov Director of Product and Engineering, NetNation
Read the NetNation story

Simple pricing, per member

Compare all plans

Learn how to run delivery with data

All articles

Questions about pull request analytics

How does AndonPulse calculate pickup time, review time and merge time?

Pickup time runs from the moment a pull request is ready for review to its first review. Review time runs from the first review to approval. Merge time runs from approval to merge. You choose how each chart calculates them: the median, the average or any percentile. Every number opens the pull requests behind it, so you can check how it was counted.

How is this different from GitHub or GitLab insights?

GitHub and GitLab show pull request activity one repository at a time. AndonPulse combines review data from all repositories with Jira or Linear. It splits the time into stages, shows the review load for each team and reviewer, and links each pull request to the Issue and Deliverable it holds up.

Is pull request analytics a separate product?

No. Pull request analytics is one view of the AndonPulse platform. It runs on the same connected data as cycle time, DORA metrics, sprint reports and delivery forecasts. A slow review queue you find here shows up in the forecast of the Deliverable it holds up, without a second setup.

Does AndonPulse read or store our source code?

No. AndonPulse reads pull request metadata, such as timestamps, reviewers and status, not the code itself. Integrations are read-only, and each customer’s data sits in a separate database with SSL/TLS and encryption of sensitive fields. The Trust Center has the details.

Does AndonPulse rank individual developers?

No. Reviewer views show how the review load is spread, so you can share it more evenly. In the B2B SaaS story, the slow reviews came from a few people doing everyone’s reviews, not from slow engineers. There are no leaderboards or individual productivity scores.

Can bots and automated pull requests be excluded?

Yes. You configure every dashboard, so you choose which accounts count as bots and whether their pull requests and reviews count. You can change the rules at any time, and past periods recalculate.

Your data. Our help getting started.

Get started with our help

Request free access to AndonPulse. We’ll schedule a guided session and help you get from connected tools to useful insights.

  1. 01

    Tell us about your team

    A few details help us tailor the session to your tools and goals.

  2. 02

    Get a guided setup session

    We’ll help you connect your tools, set up your workspace, and understand your data.

  3. 03

    Start with free access

    Use the free Developer Productivity plan for teams of up to 10, or try paid capabilities free for 14 days.

Connect your existing tools without changing your workflow.

Free access, with a helping hand

Request free access

We’ll email you to arrange a guided session before you receive access.

People whose engineering work you want to understand.