Missed another PR review request? Here's why it keeps happening

Updated August 2026 · 5 min read

It's 4 pm. A teammate pings you: "Did you see I requested your review this morning?" You didn't. GitHub sent something, somewhere — but between email, the bell icon and Slack, review requests are the easiest notification to lose. Here's why it happens, and three setups that actually fix it.

Why review requests are so easy to miss

1. Email treats them like any other notification. A review request arrives as an email from [email protected], with the same subject-line shape as twenty other threads. If your inbox is busy (and whose isn't), a "please review #142" competes with every newsletter you never unsubscribed from.
2. The bell icon only shows what's unread. Review requests do appear in the GitHub inbox, but if you already clicked past them once, they move to "Done" and vanish. There is no persistent "you still owe someone a review" state anywhere in GitHub's UI.
3. Slack's GitHub integration is opt-in per repo. Many teams subscribe Slack channels to repo activity but forget that review requests are a separate subscription. Result: CI failures ping the channel loudly, but the request aimed at you personally stays silent.
4. You're not automatically subscribed. Being assigned as a reviewer does notify you — once. If you snoozed the email or dismissed the notification, nothing re-surfaces it. GitHub assumes you saw it.

Three ways to never miss one again

1. Tune GitHub's native settings (free)

Under Settings → Notifications, make sure Participating → Email is enabled — review requests count as "participating". Then create an inbox filter that stars or labels anything from [email protected] containing "requested your review". It's manual maintenance, and filters silently break when wording changes, but it costs nothing.

2. Route requests into Slack properly

In Slack, run /github subscriptions add <repo> and make sure reviews and review requests are checked, not just issues and pulls. This works well for teams whose channel culture is healthy; it fails when the request is personal and the channel is busy — a mention of your username in a firehose channel is barely better than email.

3. Keep a live unread count in sight all day

The reason people miss requests isn't delivery — it's attention. A notification buried under 40 unread items is effectively lost. That's the problem we built DevNotify for: a small macOS menu bar app that shows your true unread count at all times and lets you jump straight to any pending review. It polls the official GitHub API locally, needs only a read-only token, and sends nothing to any server. When the number won't go to zero, you know someone is waiting on you.

The habit that matters more than any tool

Whatever setup you choose, pair it with one rule: clear your review queue to zero before lunch. Review latency compounds — a teammate blocked on your review blocks their reviewer next. Teams that keep median review time under an hour ship measurably faster, and it starts with simply seeing the request the moment it lands.