The GitHub notifications settings actually worth changing

Your GitHub notifications settings live at github.com/settings/notifications. Only a handful there are worth changing: where Watching and Participating notifications go, which email types you get, whether GitHub auto-watches repos for you, and how loud Actions is. After that, set a Watch level on each repo and let inbox filters handle the rest.

TL;DR

Send Watching notifications to the web inbox only. Don't email them.
Turn off email for pushes and for your own activity.
Turn off automatic watching if you're in a big org.
Set Actions to failed workflows only.
Use reason: filters in the inbox, and the noreply.github.com CC addresses in your mail client.

Where are GitHub notification settings, exactly?

They're spread over three places, which is half the confusion:

Account level: github.com/settings/notifications. Controls delivery, meaning web, email, or both, and which events trigger email.
Repo level: the Watch button at the top of every repository. Controls what you get from that repo.
The inbox: github.com/notifications. Doesn't change what arrives, but decides how fast you can get rid of it.

People tend to fiddle with the first one, still drown, and conclude GitHub notifications are broken. They're not broken. They're just noisy by default, and the noise comes from all three places at once. If you're not sure where notifications even show up, I covered that in where to see GitHub notifications.

GitHub's own reference for all of this is Configuring notifications. It's thorough. It's also long.

Watching vs participating is the split that matters

Under Subscriptions you'll see two rows:

Watching: everything from repos and teams you watch, whether or not you're involved.
Participating, @mentions and custom: threads you've commented on, been assigned to, been asked to review, or been @mentioned in.

Each one gets its own delivery choice. My opinion: Watching goes to on GitHub only. Never email. Watching is the firehose, and a firehose pointed at your inbox is how you end up with a Gmail filter called github-ignore that you never open.

Participating is where email can make sense, but only if your day runs out of email. If it runs out of the browser, keep that one on GitHub too and check the inbox on purpose.

The email toggles nobody reads

Further down, Customize email updates has a few checkboxes that do a lot of damage:

Reviews: an email when someone reviews a PR you're on. Keep it.
Pushes: an email for every push to a PR you're subscribed to. Turn it off. Someone force-pushing a rebase five times shouldn't cost you five emails.
Comments on Issues and Pull Requests: keep it if you're on email for participating, drop it otherwise.
Include your own updates: emails about things you did. I've never met anyone who wanted this.

While you're there, check Default notifications email. If you use one GitHub account for work and side projects, Custom routing lets you send each organization's notifications to a different address. Your employer's PRs go to your work inbox, your open source noise stays out of it.

Stop GitHub auto-watching every repo

There's a checkbox called Automatically watch repositories. When it's on, GitHub subscribes you to all activity on any repo you get push access to. In a small team that's fine. In an org with a few hundred repos, it means one org invite can sign you up for a lot of mail.

Turn it off. There's a matching Automatically watch teams option. Same reasoning applies.

Then go to github.com/watching and look at what you already watch. Expect some surprises. Unwatch anything you wouldn't want to hear about at random times.

Set the Watch level per repo

The Watch dropdown on a repo has four options:

Option	What you get	Good for
Participating and @mentions	Only threads you're involved in	Most repos, honestly
All Activity	Every issue, PR, comment, release	Repos you own and maintain
Ignore	Nothing, not even @mentions	Repos you can't leave but don't care about
Custom	Pick from issues, PRs, releases, discussions, security alerts	Dependencies you only want releases from

Custom with only Releases checked is underrated. It's the polite way to follow a library without reading its issue tracker.

Be careful with Ignore. It mutes @mentions too, so someone tagging you on something urgent gets silence.

Turn down GitHub Actions notifications

Under System, there's an Actions section. Check Only notify for failed workflows. Otherwise every green run on every branch shows up, and a green build isn't news.

Dependabot alerts have their own section in the same place, with options for web, email and a digest. If you maintain a lot of repos, the weekly email digest is much easier to live with than one email per alert.

Filter what's left in the inbox

Even with all of that tuned, the inbox at github.com/notifications still fills up. The trick is that every notification has a reason, and you can filter on it. Something like this:

reason:review-requested is:unread
reason:mention
reason:team-mention
reason:author is:pr
repo:your-org/your-repo is:unread

You can save these as custom filters in the inbox sidebar, so there's one click for review requests, one for mentions, and so on. Pressing e marks the selected notification as done, which gets you through a pile pretty quickly. Save pins a thread you want to come back to, and Unsubscribe is the right move for a thread you got pulled into by accident.

GitHub's docs on managing notifications from your inbox list every qualifier, if you want the full set.

Filtering GitHub emails in your mail client

If you do keep some email on, GitHub makes filtering easier than it looks. Every notification email is CC'd to an address that tells you why you got it:

The same reason is in the X-GitHub-Reason header. In Gmail, a filter on cc:[email protected] that applies a label and stars the email will pull review requests out of everything else. Do the same for mention, and send push and comment straight to archive.

There's more on this, including what to do once you're already buried, in too many GitHub notification emails.

Settings won't stop review requests getting lost

This is the annoying part. Notifications are events, not state. A review request notification tells you a review was requested. It doesn't tell you the PR is still waiting on you three days later. Once you mark it done, or it scrolls off the bottom, the PR is still sitting there and nothing reminds you.

Two things help here. First, search instead of scrolling. On github.com/pulls or in the search bar:

is:pr is:open review-requested:@me
is:pr is:open user-review-requested:@me
is:pr is:open author:@me review:changes_requested

review-requested:@me includes requests made to your teams. user-review-requested:@me is just the ones addressed to you by name, which is usually the list you actually owe. If the reviewer and request states are confusing, GitHub pull request reviewer status goes through what each one means.

Second, keep that list somewhere you can see it. This is what PRFlow does. It's a Chrome side panel that shows open PRs across your repos, grouped into needs my review, created by me, and reviewed but not merged, with each PR's status, labels, comment count and diff size. It works from the current state of each PR rather than from notification events, so a PR stays on the list until it's actually dealt with. And you don't have to open fourteen tabs to find out which one is yours.

What it doesn't do: it doesn't replace the notification inbox. It doesn't cover issues, Actions runs, Dependabot alerts or @mentions in random threads, and it doesn't touch your GitHub notification settings. You still want the settings above tuned. PRFlow just covers the part notifications are bad at, which is keeping track of what's still waiting on you. If you want to see how the two fit together, the GitHub PR review workflow guide has the whole setup, and the notifications tag has the rest of the posts on this.