How to Automate PR Reviewer Assignment on GitHub

Every pull request starts the same way: someone opens it, looks at the diff, and tries to figure out who should review it. They scan the blame, check who's online, maybe post in Slack asking "who knows about the billing module?"

This step — figuring out the right reviewer — adds anywhere from 10 minutes to half a day of latency before the review even starts. And it happens on every single PR.

Here's how to eliminate it.

Option 1: CODEOWNERS (built-in, limited)

GitHub's CODEOWNERS file automatically requests reviews based on file paths. Drop a file at .github/CODEOWNERS and you're set:

/src/billing/ @payments-team
/src/auth/ @security-team
*.test.ts @qa-team

Pros:

• Zero setup beyond the file itself
• Integrates with branch protection (require owner approval)
• Works at the organization level

Cons:

• Path-based only — no logic for reviewer availability, workload, or expertise
• Stale team references fail silently
• Can't rotate reviewers or balance load
• The reviewer still has to find the notification

CODEOWNERS is the right starting point. But for most teams, it's not enough on its own.

Option 2: GitHub's auto-assign (Actions or apps)

GitHub Actions can assign reviewers programmatically. The auto-assign-action is a popular community action:

name: Auto Assign
on:
  pull_request:
    types: [opened, ready_for_review]

jobs:
  assign:
    runs-on: ubuntu-latest
    steps:
      - uses: kentaro-m/auto-assign-action@v2
        with:
          configuration-path: .github/auto-assign.yml

With a config like:

addReviewers: true
numberOfReviewers: 2
reviewers:
  - alice
  - bob
  - charlie
  - diana
assignmentAlgorithm: round-robin

This adds load balancing — reviewers rotate instead of the same person getting every request. But it's still a blunt instrument. Round-robin doesn't know that Alice is on vacation or that Bob is the only one who understands the payment retry logic.

Option 3: Review bots (PullApprove, ReviewBot)

Third-party GitHub Apps add more sophisticated assignment logic:

• PullApprove: Rule-based assignment with conditions (file paths, labels, author team membership). Supports "at least 1 from team A and 1 from team B" patterns.
• ReviewBot: Assigns based on git blame data — whoever wrote most of the code being changed gets the review request.

These solve real problems but add configuration complexity. PullApprove's rule files can grow to hundreds of lines for large monorepos. And they still don't solve the notification problem.

The missing piece: notification routing

Every solution above answers "who should review this PR?" None of them answer "how does the reviewer actually see the request and act on it?"

GitHub's notification system sends review requests to:

1. Email — buried in a folder with dozens of other GitHub notifications
2. GitHub's notification inbox — which most developers check sporadically at best
3. The Slack integration — which broadcasts to a channel, creating noise that trains people to ignore it

The assignment is automated, but the communication isn't. So the reviewer gets assigned at 10:03 AM and doesn't notice until 3 PM when they happen to check their GitHub notifications. The automation saved 10 minutes of manual assignment and lost 5 hours to notification failure.

What a complete solution looks like

The best PR workflow combines automated assignment with automated notification:

1. PR opens → CODEOWNERS or round-robin assigns the right reviewer
2. Reviewer gets a direct Slack message with the PR title, description, and a link — not a channel broadcast, a DM
3. When the reviewer submits feedback → the author gets a DM
4. When the author pushes changes → the reviewer's original message updates to show the PR is ready for re-review
5. When the PR merges → the thread resolves

Each step targets a specific person with a specific action. No one else gets notified. No channel noise. No email.

Building this yourself vs. using a tool

You can absolutely build this with GitHub webhooks, a small server, and the Slack API. It's maybe a week of work for v1 — parse webhook payloads, map GitHub usernames to Slack IDs, send messages via chat.postMessage, update messages via chat.update.

The maintenance is where it gets you. Handling edge cases (draft PRs, force pushes, dismissed reviews, team membership changes), keeping the username mapping current, dealing with Slack API rate limits, and debugging why Carol didn't get notified about that critical PR on Friday afternoon.

Tenpace handles all of this out of the box. Connect GitHub, connect Slack, map your team members, and PR notifications just work. Direct messages to the right person, updates in place, no noise.

We're free during beta — set it up in three minutes.

The practical recommendation

For most teams, here's what I'd suggest:

1. Start with CODEOWNERS. Define ownership for your most important directories. Use team handles, not individuals.
2. Add round-robin for general PRs. Use a GitHub Action or app to distribute reviews that don't match a specific code owner.
3. Fix the notification layer. Route review requests to Slack DMs instead of relying on email or channel broadcasts.

Steps 1 and 2 are table stakes. Step 3 is where review latency actually drops.

Have a reviewer assignment setup that works well for your team? Let us know: hello@tenpace.com