A pull request dashboard is a single view that shows the state of every open PR across your team or repos — what’s waiting on review, what’s approved, what’s failing CI, and what’s gone stale. Instead of clicking through GitHub’s PR lists one repo at a time, you get the team’s whole review workload on one screen.
It sounds like a minor convenience. In practice it’s one of the highest-leverage views a small dev team can have, because PRs are where work goes to wait — and waiting is where velocity quietly dies.
Why PRs need their own view
GitHub is excellent at storing pull requests and surprisingly bad at showing you the team-level picture. The default PR list is per-repo, sorted by recency, and treats a three-week-old unreviewed PR the same as one opened this morning. On a team with several repos, answering “what’s actually blocking us right now?” means opening N tabs and reconstructing the answer by hand.
The lead, discovering the 19-day-old unreviewed PR.
Meanwhile, the failure modes of PR flow are remarkably consistent:
-
Review latency. PRs sit unreviewed because nobody knows they’re waiting. The author assumes someone will notice; everyone assumes someone else has it.
-
Invisible staleness. A PR with no activity in five days is usually a conversation that died, not work that’s fine.
-
CI red that nobody saw. The build failed Tuesday; the author stopped looking Monday.
-
Review imbalance. One person is the reviewer on nine open PRs and is now the team’s bottleneck — but nobody sees the aggregate.
None of these show up in a standup unless someone happens to mention them. All of them show up immediately on a dashboard.
What a good PR dashboard shows
The specifics vary, but the useful core is always the same:
-
Every open PR, across repos, with author, age, and size.
-
Review state — unreviewed, changes requested, approved — so waiting-on-whom is unambiguous.
-
CI status inline, because a green checkmark is part of “done.”
-
Staleness signals — PRs with no recent commits, comments, or reviews, sorted so the most-stuck float to the top.
-
Review load per person, so bottlenecks are visible before they’re felt.
With those five things, “how’s the sprint going” stops being a question you ask people and becomes a screen you glance at.
Dashboard vs. standup
This is the part teams don’t expect: a live PR dashboard quietly eats most of the daily standup. The standup’s first two questions — what did you do, what are you doing — are answered by merged PRs and open PRs. What’s left is the third question, blockers, which is the only one that ever needed a human conversation. We wrote the full playbook for this in how to run async standups from your GitHub activity.
The DIY options
You can build a passable PR dashboard without buying anything:
-
GitHub’s built-in views: repo-level PR lists plus saved search filters (
is:open is:pr review-requested:@me). Works, but per-repo and per-person. -
GitHub Projects: can be wrangled into a PR board with some automation. It’s a spreadsheet-shaped answer to a flow-shaped problem, but it’s free.
-
Slack bots / scheduled actions: post a daily digest of open PRs to a channel. Better than nothing; degrades into noise.
The ceiling on all of these is the same: they show PRs as a list, disconnected from the tasks and plans they belong to.
The integrated option
The more interesting version is a dashboard where PRs aren’t a separate feed but sit next to the work they implement — the task, the whiteboard sketch it came from, the CI run that validates it. That’s the model Kahoona is built on: connect your repo and it streams commits, PRs, and CI into the project board, next to your tasks, in about 30 seconds. The “PR dashboard” and the “project board” become the same thing — which is also why Jira-style boards drift from reality and this one doesn’t.
👉 See your team’s PRs on a live board — free to start
The bottom line
A pull request dashboard is a small thing with an outsized payoff: it makes waiting visible, and visible waiting gets fixed. Start with GitHub’s saved filters if you’re at zero. When the per-repo, per-person limits start to bite, graduate to a tool where PRs live next to the tasks they close — your board (and your standup) will thank you.
Related: Why commits belong next to tasks · Jira shows tickets, not truth How to Run Async Standups From Your GitHub Activity