GitHub notification settings: the complete reference

Updated August 2026 · 6 min read

GitHub's notification system has more settings than most people realise. The default configuration works for casual use, but if you're on a team with multiple repositories, the defaults are almost certainly wrong for you — either drowning you in noise or letting reviews slip through.

This guide covers every notification setting in GitHub, what each one actually does, and how to configure them for the way you work.

Where to find your notification settings

All settings live under github.com → Settings → Notifications. There are four sections on this page, and each one controls a different channel. We'll go through them one by one.

1. Notification delivery — how GitHub reaches you

Email notification settings

Under "Email notification preferences" you have three options:

• Participating only — email only when you create a thread, comment on one, or are @mentioned. This is the recommended default for most developers.
• All activity — email for every notification from repos you watch. Warning: this produces a lot of mail.
• Everything — email for every notification from every repo you have access to. Only suitable if you need an audit trail.

You can also choose to receive email as one notification per action (many small emails) or as periodic digests (hourly or daily summaries).

2. Watching — which repos notify you

For each repository you have access to, you can set one of four watch states. These are the single most impactful settings for your notification volume.

How to manage watches at scale

Under Settings → Notifications → Watching you can see every repo you're watching. The page shows a list sorted by notification volume, so you can quickly identify which repos are generating the most noise. Click "Unwatch" to switch back to Participating or "Custom" to narrow the scope.

Pro tip: if you're on more than 10 repos, check this page monthly. Accidental "All Activity" clicks are the most common cause of notification overload.

3. Subscriptions — individual thread tracking

Separate from watching, you can subscribe to individual issues, pull requests, or discussions. This is useful for a conversation you want to follow without watching the whole repo.

• Auto-subscription: commenting on a thread, opening a thread, or being assigned auto-subscribes you.
• Manual subscription: the "Subscribe" button at the bottom of every issue and PR.
• Unsubscribe: the "Unsubscribe" button in the same spot, or the "Mute" option to silence a thread temporarily.

You can see all your subscriptions at github.com/notifications/subscriptions.

4. Custom notification settings per repo

GitHub's most underused feature: the Custom watch setting. When you click "Watch → Custom" on a repo, you get a checklist:

• Issues — new issues, new comments on existing issues
• Pull Requests — new PRs, new comments, status changes (merge, close, CI failure)
• Releases — only when a new version is published
• Discussions — new discussions and replies
• Security alerts — vulnerability alerts for dependencies

This is the ideal setup for most repos. For example:

• Your team's main repo: Pull Requests + Issues + Security alerts
• A popular open-source library you use: Releases only
• A security advisory repo: Security alerts only
• An archived repo: Ignore

5. System-wide notification settings

Back in Settings → Notifications, there are a few global toggles that affect everything:

6. Organisation-level notification settings

If you're part of a GitHub organisation (team, company, open-source project), the organisation admins can set policies that override your personal settings:

• Email notification routing — org can require notification emails to go to your work email address
• Mandatory watching — org can force members to watch certain repos (e.g., security, compliance)
• Busy mode policies — org can restrict busy mode during working hours

These settings are managed by admins under Org → Settings → Notifications.

7. The problem with relying solely on GitHub's settings

Even with perfect settings, the GitHub web inbox has a fundamental limitation: it only works when you have a browser tab open to github.com. If you're working in an IDE, terminal, or any other application, you won't see the bell badge until you tab back.

That's where a desktop notification tool fills the gap — it shows your unread count in your menu bar or system tray at all times, regardless of which app has focus.

Quick reference: the ideal settings for different roles