How to Get GitHub Notifications on Your Desktop

Short answer: github.com won't push notifications to your operating system, so you need something in between. A menu bar app like Gitify is the easiest. The GitHub app for Slack works too, and so does a small script around the GitHub CLI. Pick one, then trim what you're subscribed to. Otherwise you'll get a desktop ping for every push to a repo you starred and forgot about years ago.

TL;DR

• GitHub has no built-in desktop notifications for its web inbox. You have to bridge it.
• Gitify, a menu bar app, takes the least effort.
• If Slack is open all day anyway, the GitHub app's real-time alerts cover review requests and mentions.
• gh plus a few lines of shell gets you native OS notifications without installing another app.
• Clean up your subscriptions first. If you don't, you've only moved the noise somewhere louder.

Why doesn't GitHub just do this?

GitHub sends notifications to three places: the web inbox at github.com/notifications, email, and GitHub Mobile. Your desktop isn't one of them. The GitHub docs on configuring notifications cover all three, and none of them is a native popup on your laptop.

The web inbox is fine when you have it open, and nobody does. Email can pop a desktop alert through your mail client, but then your review requests sit next to newsletters and invoices. If that's already your situation, see what to do about too many GitHub notification emails.

So the real question is which bridge annoys you least.

Fix what you're subscribed to first

Do this before you wire anything to your desktop. Each option below shows whatever is in your inbox, and a lot of that you never asked for.

GitHub separates two kinds of subscription:

• Participating: you were mentioned, assigned, asked for a review, or you commented. You usually want these.
• Watching: everything in a repo you watch. You usually don't want these on your desktop.

A few things are worth doing:

1. Go to github.com/watching and unwatch repos you don't work in. If you joined a big org, you may be watching dozens of repos automatically.
2. In Settings → Notifications, look at Custom routing if you have work and personal orgs. It only sends email to an address you choose, but it's still worth tidying.
3. Under Actions, set notifications to failed workflows only. Getting pinged about green builds gets old fast.
4. For a repo you need to follow but not closely, use Watch → Custom and pick only the events you care about, like releases or security alerts.

There's a longer walkthrough in our guide to GitHub notification settings.

Option 1: a menu bar app

Gitify is open source and runs on macOS, Windows and Linux. It reads your GitHub notification inbox, shows an unread count in the menu bar or tray, and can send native OS notifications when new items come in. You can mark items as read or open them without visiting github.com.

Why I'd start here:

• About two minutes to set up.
• It uses the inbox you already have, so all your GitHub-side filtering still applies.
• It works across every org and repo.

The catch is authentication. You sign in with OAuth or give it a personal access token. Check the REST docs for notifications to see which token types work. At the time of writing that's classic tokens, not fine-grained ones, which may be a problem if your org has opinions about tokens.

Option 2: Slack (or Teams)

If a chat app already sits on your screen and already makes desktop notifications, you can use it.

The GitHub app for Slack does two separate things, and people mix them up:

• Channel subscriptions like /github subscribe owner/repo pulls reviews comments. These are fine for a team channel but bad for personal alerts, because everyone sees everything.
• Personal alerts. Under scheduled reminders in your GitHub settings, you can turn on real-time alerts. You get a DM from the GitHub app when someone requests your review, mentions you, or comments on your PR.

The DMs are what you want. Slack's desktop notifications take care of the OS side, and you can mute everything else in Slack the way you already do.

The downside is that you now depend on Slack for something that isn't really chat. If you close Slack to get work done, which is a reasonable thing to do, you close your GitHub alerts too.

Option 3: roll your own with the GitHub CLI

If you have GitHub CLI installed, gh status already prints a summary of assigned issues, assigned PRs, review requests, mentions and recent activity across your repos. Run it in a terminal and you've got a decent pull-based dashboard.

To get push-style notifications, poll the notifications API and pass the results to your OS. On macOS, something like this:

#!/usr/bin/env bash
# Sketch: notify about GitHub notifications from the last 5 minutes (macOS)
since=$(date -u -v-5M +%Y-%m-%dT%H:%M:%SZ)

gh api "notifications?since=$since" \
  --jq '.[] | .reason + ": " + .subject.title' |
while read -r line; do
  osascript -e "display notification \"$line\" with title \"GitHub\""
done

On Linux, replace the osascript line with notify-send "GitHub" "$line" and use GNU date -u -d '5 minutes ago'. Run it every five minutes with launchd, cron or a systemd timer.

This is a sketch, not a product. Things to know before you depend on it:

• The API sends an X-Poll-Interval header, usually 60 seconds. Poll more often than that and you're being rude to GitHub's servers.
• Using since stops repeat alerts in most cases. It isn't perfect deduplication, and a notification that gets updated will show up again.
• PR titles with quotes in them will break the osascript line. If you keep using this, escape them properly.
• You can filter on .reason in the jq expression to keep only review_requested and mention, which is probably what you want.

The upside is that you control everything: no extra app and no third party holding your token.

Option 4: GitHub Desktop, if you already use it

GitHub Desktop, the Git client, can show OS notifications when checks fail on your pull request and when someone reviews it. That only covers your own PRs in repos you've added to Desktop. It won't tell you that a teammate is waiting for your review. It's handy if Desktop is already part of your setup, but don't install it just for this.

What about a browser extension?

There are extensions that put an unread count on your toolbar, and some can show desktop notifications too. If your browser is always open, that's a reasonable choice.

This is also where PRFlow comes in, so here's what it does and doesn't do. PRFlow doesn't send desktop notifications. It's a Chrome side panel that lists your open pull requests across repos, with review status, labels, comment counts and diff size. It has filters for the questions you actually have, like "needs my review" (review-requested:@me), "created by me", and "reviewed but not merged".

A notification tells you something happened. It doesn't tell you where things stand now. After a ping, you still have to open the PR, check whether CI passed, see whether someone else already approved it, and decide whether it needs you yet. PRFlow keeps that view next to whatever tab you're in, so you don't end up with fourteen PR tabs open. It works well alongside any of the options above: let them ping you, and use the side panel to triage.

Which one should you pick?

My opinion: start with Gitify or the Slack DMs. Only build the script if both annoy you.

Make the alerts worth reading

Once notifications reach your desktop, every bad one costs you more because it interrupts you. A few inbox habits help:

• Filter the inbox with reason:review-requested, reason:mention, reason:assign and is:unread. Combine them with repo:owner/name when you're focused on one project.
• Save the filters you use most as custom filters in the inbox sidebar.
• Unsubscribe from a thread once you're done with it. Being done with a PR doesn't stop the notifications on its own.
• Turn off Include your own updates, unless you like being told about your own comments.

If you're not sure where each kind of alert ends up, where to see GitHub notifications maps it out. If review requests in particular keep piling up, the problem is often the process, not the alerts. The PR review workflow guide is a good place to start on that.