Where to See GitHub Notifications and Actually Keep Up

Short answer: go to github.com/notifications, or click the bell icon in the top-right corner of any GitHub page. That's your inbox. Email, the mobile app and the CLI all show the same stream in different places. Which one you should actually live in depends on how much of that stream you care about, which for most of us is not much.

TL;DR

• Web inbox: the bell icon, or github.com/notifications
• Where notifications get sent (web, email, mobile): github.com/settings/notifications
• Why you're getting so many: github.com/watching
• From the terminal: gh status
• Review requests specifically: search is:open is:pr review-requested:@me, because the inbox isn't reliable for these

Where is the GitHub notifications inbox?

It's the bell. When it has a blue dot, you have unread notifications. Click it and you land on the inbox, which has three views in the left sidebar:

• Inbox: everything that hasn't been marked done
• Saved: things you bookmarked to deal with later (and, let's be honest, never will)
• Done: things you've cleared, in case you cleared something by accident

Under those are default filters like Assigned, Participating, Mentioned, Team mentioned and Review requested. Further down, notifications are grouped by repository, so you can click one repo and see only its noise.

One thing that confuses people: marking something as read and marking it as done aren't the same. Read just removes the bold. Done takes it out of the inbox. If you only ever read things, your inbox grows forever and slowly turns into a museum.

Filters that make the inbox usable

The search box at the top of the inbox takes qualifiers. These are the ones I actually use:

You can combine them, like reason:review-requested is:unread org:your-org, and save combinations as custom filters so they sit in the sidebar. GitHub's docs on managing notifications from your inbox list all the supported qualifiers.

Keyboard shortcuts

If you triage in the web inbox, learn these and you'll get through it a lot faster:

• E: mark as done
• Shift + I: mark as read
• Shift + U: mark as unread
• Shift + M: unsubscribe from the thread

That last one is underrated. If a thread you got pulled into once keeps pinging you, unsubscribe and you're out.

Where your notifications get sent is a setting

You control this at github.com/settings/notifications. For each category you pick where it goes: on GitHub (the web inbox), email, and GitHub Mobile, where it applies. The categories that matter most:

• Participating, @mentions and custom: threads you're involved in
• Watching: everything in repos you watch
• GitHub Actions: workflow runs, with an option to only notify on failures
• Dependabot alerts: security alerts for repos you have access to

There's also Custom routing, which sends email for each organization to a different verified address. That's handy when your work and personal accounts are the same GitHub account and you don't want client repo email showing up in your personal inbox.

If your problem is that your inbox is full of GitHub mail, I wrote a whole post on cutting down GitHub notification emails. The short version: turn off email for Watching, keep it on for Participating, and see if anyone notices.

Why am I getting notifications I never asked for?

Almost always it's because you're watching a repo. Watching a repo means you get notified about everything that happens in it. Go to github.com/watching and you'll probably find a long list of repos you don't remember subscribing to.

Two settings cause most of this, both on the notifications settings page:

• Automatically watch repositories: on by default. Every time you get push access to a repo, you start watching it.
• Automatically watch teams: same thing, but for team discussions when you join a team.

Turn off the first one unless you really want to hear about every issue in every repo you can push to. Then go through the watch list and set each repo's Watch dropdown to one of:

• Participating and @mentions: the sane default
• All Activity: only for repos you actually own
• Custom: pick events like Releases or Pull requests
• Ignore: not even mentions get through. Use with care.

GitHub's notification configuration docs cover what counts as "participating". The short version: you commented, you were mentioned, you were assigned, you opened it, or someone requested your review.

Can I see GitHub notifications on my phone?

Yes, with GitHub Mobile (iOS and Android). It has its own notifications inbox that mirrors the web one, and you can turn on push notifications for things like direct mentions, review requests, and assignments. You configure push on the phone itself, and it's separate from your email settings.

My honest take: push for review requests and mentions is fine. Push for everything else is a good way to learn to ignore your phone.

Checking notifications from the terminal

If you live in a terminal, the GitHub CLI has two useful options.

gh status prints a summary across all your repos: assigned issues, assigned PRs, review requests, mentions, and recent activity in repos you're involved in.

# Overview of everything that wants your attention
gh status

# Same, limited to one org
gh status --org your-org

For the raw notification stream, use the REST notifications endpoint through gh api:

# Titles of unread notifications
gh api notifications --jq '.[].subject.title'

# Only threads you're participating in
gh api 'notifications?participating=true' --jq '.[] | .repository.full_name + ": " + .subject.title'

# Mark everything as read (no undo, so think first)
gh api -X PUT notifications

The API returns a reason field on each notification (review_requested, mention, assign, ci_activity and so on), so you can script your own filtering if the built-in views don't fit.

The inbox is bad at one thing: open review requests

This is the part that bites people. Notifications are events, not state. The inbox tells you that someone requested your review at 10:14 on Tuesday. It doesn't tell you that the PR is still waiting on you now.

So if you mark that notification done, or it gets buried under forty Dependabot alerts, the review request is gone from your inbox. The PR still says you're a requested reviewer. Your teammate is still waiting. You have no idea.

For anything that's still open, use search, not notifications:

is:open is:pr review-requested:@me
is:open is:pr author:@me
is:open is:pr reviewed-by:@me -author:@me

The first is "what's waiting on me", the second is "what I'm waiting on", and the third is "stuff I've reviewed that hasn't merged yet". Paste them into the search bar or use github.com/pulls, which has tabs for some of these. Note that review-requested:@me matches requests made to you directly. Team requests use team-review-requested:your-org/your-team. There's more on how those states work in GitHub PR reviewer status.

The annoying part is where those results live. They're in a tab, which you end up keeping open next to the PR you're reviewing, the CI run, the linked issue and the PR you got distracted by. Fourteen tabs later you're looking for a way out of tab hell.

This is where PRFlow helps. It's a Chrome extension that puts those PR lists in the browser side panel: needs my review (review-requested:@me), created by me, and reviewed but not merged, across all your repos, with status like pending or changes requested, labels, comment counts and diff size. It stays open next to whatever tab you're on, so you can check what's waiting without leaving the diff you're reading.

What it doesn't do: it isn't a notification inbox. It won't show you issue mentions, Actions failures, Dependabot alerts, release notifications or discussion replies. For those you still use the bell, email or gh status. PRFlow covers PRs that are waiting on someone, not the event feed.

A setup that doesn't drown you

There's no correct configuration, but something like this works for a lot of people:

1. Turn off Automatically watch repositories.
2. Go through github.com/watching and drop most repos to Participating and @mentions.
3. Email on for Participating, off for Watching.
4. Actions notifications for failed workflows only.
5. Save a custom inbox filter for reason:review-requested is:unread and one for reason:mention.
6. Track open review requests with search or a side panel, not the inbox, because that's state, not an event.

If you want a fuller version of step 6, including how to batch reviews instead of reacting to every ping, the PR review workflow guide goes into it. And if you're on a team where nobody can merge without approval, getting this right is the difference between being the bottleneck and not.

One last tip: when a notification shows up for a thread you'll never act on, press Shift + M and unsubscribe. Do that a few times a day for a week and your inbox gets noticeably quieter. Browse more posts on notifications if you're still fighting it.