A practical pull request dashboard for engineering teams

Pull requests are where much of a software team's work becomes visible. They are also where work can quietly stall: a review waits for the right person, a check fails without anyone noticing, or a large change keeps growing because nobody is confident enough to merge it.

A useful pull request dashboard does not try to reproduce every screen in GitHub. Its job is to make the next useful action obvious.

Start with questions, not charts

Before choosing widgets or metrics, write down the questions the team needs to answer during a normal day:

• Which pull requests are ready for review?
• Which changes are blocked by a failing check?
• What has been waiting longer than the team considers healthy?
• Is one repository or team carrying an unusual review load?
• Which pull requests are safe to merge now?

These questions create a much better dashboard than beginning with every field the GitHub API can return. If a number does not lead to a decision, it probably does not need permanent space on the board.

Put urgent work before aggregate metrics

The first row should show work that needs attention. A compact list of open pull requests can combine repository, author, review state, check state and age without forcing someone to open five tabs.

Use explicit states rather than relying on colour alone. Labels such as review needed, changes requested, checks failing and ready to merge are faster to scan and remain accessible to people with colour-vision differences.

Aggregate metrics belong below the action queue. They are valuable for understanding trends, but a median review time cannot tell a developer which pull request to pick up next.

Treat age as a prompt for conversation

An ageing view is useful when it creates a shared habit rather than a leaderboard. Group open pull requests into a few understandable buckets—for example, under one day, one to three days, and over three days—and agree on what the team will do when work crosses a boundary.

The right response might be to ask for a second reviewer, split the change, clarify ownership or close work that is no longer needed. The dashboard surfaces the conversation; it should not pretend to know the cause.

Keep repository context visible

Teams often work across services with very different risk profiles. A two-day pull request in a fast-moving frontend repository may be unusual, while the same age in a carefully reviewed infrastructure repository may be expected.

Always keep the repository name beside the pull request, and let people narrow the view to the repositories they own. If the dashboard combines several GitHub installations, keep account and installation boundaries intact as well. Convenience is not a reason to blur authorization.

Pair the board with a lightweight routine

A dashboard improves flow only when the team knows how to use it. A simple routine is enough:

1. Check failing CI and requested changes before starting new work.
2. Review the oldest ready pull request in your area.
3. Raise blocked work during stand-up instead of letting it age silently.
4. Review the trend once a week and change the workflow before adding another metric.

The goal is not to minimize every duration. It is to reduce unexplained waiting and make collaboration easier.

Build the smallest board that changes behaviour

Start with open pull requests, CI status and an ageing view. Run that setup for two weeks. If the team still cannot answer an important question, add one focused view for it. If a widget never changes a decision, remove it.

That restraint is what makes a dashboard calm. The best board is not the one with the most data; it is the one the team can understand in a few seconds and trust enough to act on.