GitHub email notifications are noise dressed up as a to-do list. The fix is two steps: turn the noisy ones off in GitHub settings, then track the thing that actually needs action — your pull requests — in a dedicated inbox instead of your email client.
Why does GitHub send so many emails?
By default GitHub emails you about almost everything you touch: every comment on
a thread you're subscribed to, every @mention, every CI status, every review
request, every push to a PR you opened. Subscribe to a busy repo and a single
afternoon can bury fifty messages in your inbox.
The problem is that email flattens all of it to the same priority. A "someone reacted 👍" notification looks exactly as urgent as "you're blocking a release." So you either read everything (a tax on your attention) or you start ignoring the folder entirely (and miss the one that mattered).
Should you turn off GitHub email notifications?
Mostly, yes — turn off the firehose and keep only what you can't get any other way. Email is a bad task queue: it has no concept of "done," it doesn't deduplicate, and it doesn't reflect the current state of a PR (only the moment each message was sent).
You can tune this at github.com/settings/notifications:
- Switch Participating and Watching from Email toward the on-site web notifications where you can.
- Set Watching to Participating and @mentions instead of All Activity for repos you don't own.
- Turn off email for CI / Actions results — your PR checks already show that.
That cleans the inbox. But it leaves a gap: where do the notifications that do need action actually go?
Where review requests should live instead
Notifications that require you to do something are almost always about a pull request: a review was requested, your PR got changes, something you reviewed is ready to merge. That's not email-shaped work — it's inbox-shaped work.
PRFlow puts exactly that in Chrome's side panel: a single, deduplicated, always-current list of the PRs that need you, grouped by role:
- Pull requests waiting on your review
- Your own open pull requests
- PRs you've reviewed but not yet merged
Unlike an email, the list reflects the live state on GitHub — when a PR merges or a review lands, it updates, instead of leaving a stale message you have to mentally reconcile.
Email noise vs. an actionable PR inbox
| GitHub email | PRFlow side panel | |
|---|---|---|
| Deduplicates | No — one PR, many emails | Yes — one PR, one row |
| Reflects current state | No — frozen at send time | Yes — live from GitHub |
| Scope | Everything (comments, CI, reactions) | Pull requests that need you |
| Lives where you work | Separate inbox | Beside your tabs, always visible |
A recommended notification setup
Here's a concrete configuration that kills the noise without going dark on the things that matter:
- Default to web, not email. In notification settings, move Participating and Watching toward GitHub's on-site inbox. Keep email only for a narrow set you'd genuinely miss otherwise (e.g. security alerts).
- Watch repos as "Participating and @mentions." Watching → All Activity on an active repo is the single biggest source of email flooding. Switch it unless you truly need every event.
- Mute threads you're done with. Unsubscribe from a PR or issue once your part is finished so follow-up chatter stops reaching you.
- Turn off Actions/CI email. Your checks already render on the PR; you don't need an inbox copy.
- Track actionable PRs in an inbox, not email — see below.
The goal isn't zero notifications. It's that every notification left is one you actually want, and the high-volume "PRs need me" category moves to a surface built for it.
Be clear about what this replaces
PRFlow is a pull-request inbox — it's honest about its scope. It won't
surface issue comments, discussion threads, or raw CI logs; for those, keep the
narrow set of GitHub emails or web notifications you actually want. What PRFlow
replaces is the part of your inbox that was really just "PRs need me, somewhere
in here." The token it uses is stored locally in chrome.storage.local, only
talks to api.github.com, and PRFlow is read-only — it never writes to your
repos.
Frequently asked questions
How do I stop GitHub from sending so many emails?
Go to github.com/settings/notifications and move Participating and Watching from email toward GitHub's on-site web notifications, set busy repos you don't own to Participating and @mentions instead of All Activity, and turn off email for Actions/CI results. That kills most of the GitHub notification overload while keeping the handful of alerts you actually want.
How do I turn off GitHub email notifications completely?
In notification settings you can uncheck email as a delivery method for Participating and Watching, leaving only the categories you opt into (such as security alerts). Most developers don't go fully dark — they turn off the firehose and route the one category that needs action, pull requests, to a dedicated inbox instead.
How do I get GitHub notifications in Chrome instead of email?
Use a Chrome extension that surfaces GitHub activity in the browser. PRFlow puts your actionable pull requests — review requests, your open PRs, and reviewed-but- unmerged PRs — in Chrome's side panel, so the PR notifications that matter live where you work rather than in your email client.
Will I miss important notifications if I turn off GitHub emails?
Not if you replace email with the right surfaces. Keep on-site GitHub notifications for issues and discussions, keep email only for things like security alerts, and track pull requests in a PR inbox. Each notification then lands where it's actionable instead of flattening into one noisy email folder.
Turn down the firehose, then install PRFlow from the Chrome Web Store and let your pull requests live somewhere you'll actually look.
Related: Too many GitHub tabs? and the complete GitHub PR review workflow guide.