← FinOpsAid blog
Is our review process the bottleneck? How to read the Pull Requests page without turning it into a scoreboard
Open backlog, median time to close, review actions and the comment leaderboard — what each number measures, why the tracking floor matters, and which of these should never be used to rate a person.
Pull Requests is the one page in FinOpsAid with no dollar sign on it. It's here because review latency is the flow constraint that most often explains why CI cost and developer cost look the way they do — a 200-hour median time to close means work is sitting in a queue, and queues cost money in ways no billing API reports.
It's also the page most easily misused. Two of its cards rank people by name. Read the section on that before you show this page to anyone.
The tracking floor — read this first
The earliest date shown is a capture limit, not a quiet period. This matters most for the backlog chart, where the line naturally starts low and climbs as the sample fills in.
The KPI row
| Tile |
What it counts |
Direction |
| Pull Requests |
Total PRs tracked. Footnote: "latest ~100 per repo". |
Neutral — it's a sample size, not an outcome. |
| Open |
Currently open PRs. Footnote breaks the rest into merged and closed-unmerged. |
Lower is generally better — open PRs are work in progress that isn't shipping. |
| Median time to close |
Median hours from open to close, humanised into minutes / hours / days. Footnote shows the mean alongside. |
Lower is better. |
| Review actions |
Total submitted reviews (approve, changes-requested, commented). Footnote: total comments. |
Neutral — activity, not quality. |
| Reviewer of the moment |
The single most active reviewer by review count, with their total. |
Not a ranking of merit. See below. |
The median-and-mean pairing on tile three is deliberate and is the most useful thing on the row. If the mean is far above the median, you have a tail — most PRs close quickly and a handful sit for weeks. Fixing a tail is a different intervention from fixing a slow median: the tail is usually a few specific PRs nobody owns, while a slow median is a process problem.
A closed-unmerged count that rivals the merged count is worth a look too. Work that gets abandoned after review consumed CI minutes and reviewer hours for nothing.
Open PR backlog over time
The primary chart: open PRs outstanding as of each day, not opened per day. It's a cumulative level, like a queue depth, so it should be read the way you'd read a support-ticket backlog. A rising line means PRs are being opened faster than they're being closed, regardless of how hard anyone is working.
The header carries an "as of last sync" date. The Period filter (defaulting to 90 days here, longer than most pages) scopes it.
Opened per day and Closed per day
The two bar charts beneath split the backlog into its causes. Read them as a pair:
- Opened high, Closed low → intake exceeds throughput. The backlog is growing.
- Opened low, Closed high → a cleanup happened, or a release merged a batch.
- Both flat, backlog high → a stable queue of stuck work. This is the worst pattern, because nothing about it looks alarming day to day.
The two leaderboards — and what they are not
Neither board ranks people. The first identifies where review effort concentrates; the second identifies who is absorbing it — which is a bus-factor question, not a performance one.
The most defensible use of the reviewer board is spotting concentration: if one name carries most of the org's review actions, that person is a single point of failure and probably a bottleneck for everyone else's cycle time. That's an organisational finding with a clear fix, and it doesn't require judging anyone.
Recent pull requests
The detail table, newest first, showing the most recent PRs across every repository:
| Column |
Meaning |
| PR |
Number and title, linking straight to GitHub. |
| Repo |
Links to that repository's page in FinOpsAid. |
| Author |
GitHub login, or a dash where unavailable. |
| State |
open (blue), merged (brand colour), or closed (grey) — merged and closed-unmerged are visually distinct on purpose. |
| Comments / Reviews |
Counts on that PR. |
| Open time |
How long it was (or has been) open, humanised — 45 m, 6 h, 3.2 d. |
Sorting by Open time in your head down this column is the fastest way to find the specific PRs producing the tail in your mean-versus-median gap.
What people get wrong on this page
- Reading early history as a quiet period. It's the tracking floor.
- Using the comment board as a performance metric. The card explicitly says it isn't one, and high comment counts have opposite causes.
- Reading the backlog chart as "PRs opened". It's a running level, not a rate. The rate charts are below it.
- Quoting the mean without the median, or vice versa. The gap between them is the actual insight.
- Expecting real-time. Everything is as of last sync.
The 60-second read
- Backlog chart shape: flat, climbing, or falling.
- Median versus mean on the KPI row — is there a tail?
- Opened versus Closed per day, to attribute the backlog's direction.
- Reviewer board for concentration, not for ranking.
- Recent PRs sorted by Open time, to name the specific stuck items.
Frequently asked questions
Why does the pull request history start so recently?
The page is built from the latest roughly 100 pull requests per repository, so history begins wherever that sample reaches back to — the tracking floor. A busy repo hits that limit in weeks. Selecting a longer period does not create history before the floor.
What does the gap between median and mean time to close mean?
A mean far above the median means you have a tail: most pull requests close quickly while a handful sit for weeks. That is a different problem from a slow median. A tail is usually a few specific unowned PRs; a slow median is a process problem.
Is the reviewer leaderboard a performance ranking?
No. It counts review actions submitted, which measures the review load a person carries rather than the care they take — a rubber-stamp approval counts the same as a thorough review. Its most defensible use is spotting concentration, where one person is a bottleneck and a single point of failure.
Want to see your own review flow? Connect your GitHub org — read-only and free during beta — or explore the demo first. Next: how to read the Teams page.