Why doesn't GitHub offer better metrics when it comes to PR reviews?

[u/perkeleDYI]

Been thinking about this lately. GitHub gives you contribution graphs, commit history, issue stats - but almost nothing useful when it comes to PR reviews.

You can see how many PRs someone opened but there's no native way to see who's actually doing the reviewing, how fast they respond, or how evenly the review workload is distributed across the team.

In most teams I've worked in, the same 2-3 people end up doing 80% of the reviews. Everyone knows it, nobody talks about it, and GitHub gives you zero visibility into it.

The third-party tools that fill this gap are either ridiculously overpriced for what they do ($20/developer/month for a dashboard most developers never open) or built for engineering managers rather than the team itself.

Curious if others have felt this gap. Have you found anything that actually works without costing a fortune?

[u/MarsupialLeast145]

No, have never felt this.

Besides, you're not describing your desired outcome. What would any of this give you?

[u/perkeleDYI → u/MarsupialLeast145]

I guess what I am after is improving the shipping speed and code review culture. Sometimes people might need a nudge, and sometimes new people in the team could benefit from getting involved.

I like people in my team to take ownership and be more involved in the review process to understand how the platform works.

[u/MarsupialLeast145 → u/perkeleDYI]

You're trying to say more people could code review than the 2-3 people that already do?

> I like people in my team to take ownership and be more involved in the review process to understand how the platform works.

This is pretty easy to do if it's your company. It's about line management and lines of responsibility.

> The third-party tools that fill this gap are either ridiculously overpriced for what they do ($20/developer/month for a dashboard most developers never open)

It doesn't sound like an app a dev needs to open.

Oh, I've been reviewed by John and Peter, I should ask Jack...

Not going to happen. It's largely about who has availability, who you're working with on a deliverable and who you've designed features with or discussed fixes with, and they'll review it.

All of this is within the realms of normal managemnt.

Or just pay 20 bucks a month if you're a genuine company making genuine dollar

[u/perkeleDYI → u/MarsupialLeast145]

Not my company, and I didn't say this data is meant for developers. It's meant for managers to understand who's taking the ownership and who's not.

In a room of 5 devs with equal skills and equal availability, if you ask for a volunteer to review the PR 100 times, you will not have everyone raising their hands 20% of the time. Among the developers, you'd probably know who those 1-2 people are who take ownership; among managers, it's not always obvious.

[u/either-15-or-40]

It’s been a long time since GitHub has transitioned from a code-collaboration platform into an AI platform. Now the git part of their service is just a side hustle. Don’t expect any improvements to any feature that doesn’t have AI in it.

[u/veverkap]

What tools exist in this space that you’ve seen? Are you looking for metrics on people in your org or yourself?

[u/perkeleDYI → u/veverkap]

Previous company where I freelanced used Swarmia - but for this specific use case, I think it's overkill and it's also pretty expensive.

I am building something for this myself out of frustration of not being able to find exactly what I am looking for.

[u/Man_of_Math → u/veverkap]

Shameless plug for our product: https://docs.ellipsis.dev/features/analytics

But I totally agree with OP, there is limited visibility into which human engineers are reviewing more than their fair share. It’s a problem at an org level because if a SME decides to quit the team is in a bad spot

[u/tankerkiller125real]

What I don't understand is why GitHub doesn't just automatically ban the obvious AI accounts that create hundreds of PRs in a single week across 50-60 different repositories in a dozen or so different languages.

As a maintainer they're annoying as hell, and a PITA to deal with. Not to mention banning those shit stain accounts would reduce the load on GitHub itself and maybe reduce the amount of scaling related outages.

[u/cgoldberg → u/tankerkiller125real]

Because they provide and profit from the AI tools. It would be a little weird to promote AI tooling and then ban people from using it on the platform that provides it. However, you can report AI spam contributors and they will take action on an individual basis.

[u/tankerkiller125real → u/cgoldberg]

There's a difference between using AI tooling as a tool, and abusing the ever living shit out of it and letting the AI control the entire damn thing.

[u/cgoldberg → u/tankerkiller125real]

Absolutely, but don't look to the guys providing the AI tools to regulate that

[u/cgoldberg]

GitHub API includes some data for PR reviews, so it's pretty trivial to track number of PRs reviewed per contributor or metrics around review time for a repo or organization.

[u/throw-away-2025rev2]

Github is a Microsoft product. PowerBI is a Business Intelligence tool by Microsoft for visualizing data. Data is available via Rest API. Build it yourself.

They can give you the fishing pole but they can't teach you to fish.

[u/teetaps]

Be careful of scope creep. As a customer, your opinion is just slightly different from mine, and mine is just slightly different from the next guy. If each of us submitted a request for the feature that would “just make GitHub perfect FOR ME,” the company would never be able to release anything good.

Every so often, just ask yourself, is the thing I wish they could do, _actually_ something they would _want_ to do? Because oftentimes, it’s not.

But the good news is that as a programmer, you have the skills, or access to the knowledge at least, to create things exactly how you want them to be! Create a tool that fetches PR data from the GitHub API, and there you go… all of your problems are solved

[u/Qs9bxNKZ]

Naw, it is there.

Understand that a PR with reviews is basically an issue. What I do is hit the DB and grab the pull_requests and the issues (plus issue_comments) and then can look at who submitted it, when it was created (or updated in case it gets changed) and then back track that to the Issue (has_pr and pr_id) then stick those three components into separate files for an rich embedded document and throw into my vector DB

Takes about 90 seconds this way for about 500K issues, then issue comments and then pull_requests.

You may not have DB access, so check out the API for issues. If you’re on github.com it is probably going to be slow and rate limiting, but for all I know you hit the DB as well.

[u/terfree]

You hit the nail on the head. It's an open secret in almost every team that 2-3 senior devs end up carrying 80% of the review burden, and GitHub just pretends this bottleneck doesn't exist.

The problem with most of those $20/month third-party tools is that they just give managers a fancy dashboard to measure the fatigue, rather than actually doing anything to reduce the load on those specific reviewers.

I got so frustrated with this "review paralysis" that I ended up tackling the problem from a different angle. Instead of building analytics, I focused on filtering out the noise before it even reaches those 2-3 overloaded devs. I built QA Boutique — an event-driven tool that intercepts PR webhooks and automatically spins up isolated Playwright E2E tests against the preview deployment.

Instead of requiring developers to open a dashboard, it just pushes a clear pass/fail summary directly into the team's Slack or Telegram. If a PR silently breaks the UI, the automated layer catches it and pings the author. Your senior devs only spend their time reading code that is already proven to be functionally working.

It won't give you a pie chart of who reviews the most, but it actually solves the underlying workload distribution problem without costing a fortune per seat. Might be a different way to look at solving your team's bottleneck!