Skip to content

Code Review Load Balancer

Example prompt: "When a new PR is opened on our main repo, check how many open review requests each person on the backend team currently has on GitHub, pick the reviewer with the fewest, assign them, and post in the PR's Slack thread who got it and why."

How to automate code review assignment with GloriaMundo

The Problem

Most teams either use GitHub's round-robin reviewer assignment or leave it to the PR author to pick someone. Round-robin does not account for who is already buried in reviews, and manual selection tends to default to the same two or three people who respond quickly. The result is an uneven review load: some engineers are constantly context-switching to clear their review queue while others rarely get assigned. PRs that land on a busy reviewer sit for days, slowing down the whole team.

How GloriaMundo Solves It

We build a workflow triggered by a GitHub webhook when a pull request is opened. A code step defines the pool of eligible reviewers for the repository — you can hardcode a team list or pull it from a GitHub team. An integration step queries GitHub for each reviewer's currently assigned open pull request reviews across the organisation. A code step counts each person's pending reviews and selects the reviewer with the fewest outstanding assignments. If two reviewers are tied, the tie-break rule is to select the longest-idle reviewer — the one whose most recent review assignment is the oldest, meaning they have waited the longest since their last review. An integration step assigns the selected reviewer to the PR on GitHub. A final integration step posts a message in the PR's associated Slack thread explaining who was assigned and their current queue depth. Glass Box preview lets you see the queue counts and the selection logic before the assignment goes through.

Example Workflow Steps

  1. Trigger (webhook): Fires when a new pull request is opened on the repository.
  2. Step 1 (code): Define the eligible reviewer pool — a list of GitHub usernames or members of a GitHub team.
  3. Step 2 (integration): For each eligible reviewer, fetch their currently assigned open PR reviews from GitHub.
  4. Step 3 (code): Count pending reviews per person, rank by fewest assignments (tie-break by the longest idle — select the reviewer whose most recent review assignment is the oldest), and select the best candidate.
  5. Step 4 (integration): Assign the selected reviewer to the pull request on GitHub.
  6. Step 5 (integration): Post a message in the PR's Slack thread noting who was assigned and their current review load.

Integrations Used

  • GitHub — source of the PR event, reviewer queue data, and reviewer assignment
  • Slack — notifies the team channel or PR thread about the assignment and rationale

Who This Is For

Engineering teams of 4 or more developers where code review bottlenecks slow down merges, particularly teams that have tried round-robin assignment and found it does not account for real workload.

Time & Cost Saved

The direct time saving per PR is small — perhaps 2-3 minutes of thinking about who to assign. The real value is in reducing review wait times. When reviews are distributed evenly, PRs get reviewed faster and the team ships more consistently. For a team opening 15-20 PRs per week, balancing the load can shave hours off the average time-to-merge across the board. The workflow runs a few integration and code steps per PR.