How to Stop GitHub Notifications From Burying a Real Feature Request
You keep it from getting lost by making the important request look different from everything else in the inbox, because by default GitHub gives it no visual or structural edge at all. A feature request filed by your best customer and a Dependabot PR comment land in the same list, sorted by time, tagged with the same generic subscribed or mention reason. Nothing in the native inbox tells you which one matters more.
That's not a bug in GitHub's design, it's the shape of the feature. Notifications are built to tell you that something happened, not how much it matters. Fixing that means tightening the native settings so less noise arrives in the first place, then adding a layer on top that ranks requests by who's asking, since GitHub itself has no concept of that.
Why one real request looks identical to noise
GitHub's notification model has exactly two subscription types, and most of the flood comes from the broader one. Watching a repository subscribes you to every piece of activity in it. Participating is narrower and automatic. You're notified when you comment, get @mentioned, are assigned, or a team you're on gets mentioned. If you watch ten active repos, you get every issue, every comment, every label change, every bot PR across all ten, in one merged inbox.
The inbox does label each item with a reason, things like mention, subscribed, or review requested, per GitHub's own docs. That's a category, not a priority. subscribed covers a one-line typo fix and a customer's fourth follow-up on a blocked migration with the exact same label. And web inbox notifications only stick around for five months before GitHub drops them, unless you've marked one Saved. A request that scrolled past you six months ago isn't just buried; it's gone.
One maintainer's public account of this is worth reading in full. Chris Wilcox, who works on Google's Cloud client libraries, put it plainly: "not all issues are of equal importance; some in fact aren't important at all." His team releases libraries across seven-plus languages and 300-plus repositories total; his own focus area, storage and database products, still ran to 30-plus repos to keep an eye on. His fix started with the same root cause described above, GitHub auto-subscribing him to more and more repos over time, and worked backward from there.
The native settings that cut the noise
Before anything else, three changes to GitHub's own settings remove a real slice of the problem, and they cost nothing:
- Turn off auto-watch. GitHub subscribes you to every repo you push to, open a PR against, or get added as a reviewer on, by default. A second practitioner writeup on the same problem points to unchecking "Automatically watch repositories" in your notification settings as the first fix, since it's what makes the watch list grow on its own instead of by choice.
- Unwatch deliberately. Wilcox audited which of his watched repos needed his attention and dropped the rest, landing on a working set of 20 to 40. The same logic applies at any scale. A repo you contributed to once eighteen months ago doesn't need to keep filing into your inbox today.
- Use the inbox's own filters. The notifications inbox supports query filters like
reason:review-requestedto narrow by why you were notified, anis:savedquery for anything you've flagged to revisit, and aDoneaction (is:done) to clear items you've handled, keeping the active list closer to what still needs a look.
None of this ranks a request by who filed it. It just clears enough clutter that a real one has a chance of being read before it ages out.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionHow Milo's request got buried anyway
Milo Kowalczyk maintains opslog, an open source CLI for tailing structured logs across a fleet of servers, on nights and weekends alongside a full-time infra job. The project has around four thousand GitHub stars, and a dozen or so companies pay a small monthly fee for a priority-support tier that includes faster bug turnaround and a shared Slack Connect channel with Milo directly. Everyone else uses opslog free. His notifications run thirty to sixty items on an average day: Dependabot bumps, CI failures on forks, drive-by typo PRs, and the occasional real issue.
One of those paying customers, a team at a mid-sized logistics company, had been running opslog in production for a year. Their lead engineer filed a GitHub issue asking for structured JSON output instead of the tool's plain-text default, something their alerting pipeline needed to parse the logs at all. The same afternoon, worried the issue alone might not get seen fast enough, she also dropped a note in the paid-tier Slack Connect channel and CC'd Milo's support address.
Issue comment, from the reporting team's lead engineer. We're piping opslog output into our alert router and currently regex-parsing plain text lines, which breaks every time a message format changes. A
--jsonflag would let us drop that entirely. Happy to open a PR if you'd take it.
The GitHub issue sat, tagged subscribed like everything else, three notifications deep in a Tuesday that also included nine Dependabot comments and a CI failure on an unrelated fork. The Slack note and the support email landed in two inboxes Milo checks separately, and nothing tied the three together as one ask. He saw the original GitHub notification, meant to reply, and didn't open it again until a contributor pinged him in an unrelated thread five weeks later asking if the JSON flag idea had gone anywhere.
Milo, replying late. Sorry, this got buried under a pile of dependency bumps. Yes, let's do it, can you open that PR?
Nothing about the request was ambiguous. It named a production dependency, came from one of the project's paying accounts, and arrived through three separate channels the same day. What buried it was structural. Each copy looked, on its own, exactly like every low-stakes item around it, and nothing in GitHub, Slack, or email knew the other two existed.
Where the manual fixes run out
The settings above genuinely help, and they're worth doing regardless of anything else. But they all share the same ceiling. None of them know which requester is your biggest account, your newest customer, or someone who's asked the same thing three times across three different channels, the way Milo's paying customer did without either of them realizing it. GitHub's notification system has no concept of a customer at all, only a username and a repository.
That gap starts to matter once a project has more than a handful of contributors and users, or once feedback about the same repo is arriving in Slack, a support inbox, or sales calls at the same time GitHub notifications are piling up. At that point, "which of today's forty notifications deserves a reply first" stops being answerable by reading labels and starts requiring someone to already know who each person is.
That's the point where we'd point you at Modem. It connects to your GitHub repos alongside Slack, support tools, and email, and turns issues, comments, and mentions into tracked topics instead of a flat list of events. Because Modem already knows the people and companies behind every channel it watches, a request like the logistics team's would have shown up once, not three times, with the GitHub issue, the Slack note, and the support email all attached to the same topic and the same account instead of competing for attention as three separate items. The daily digest ranks topics using those unified company and account profiles, built to separate who matters from who can wait, rather than sorting by timestamp the way GitHub's inbox does. We build Modem, and the honest version of that pitch is narrower than the paragraph above makes it sound. If your repo's requests come almost entirely from a small, known set of people you'd recognize by username anyway, the settings above are genuinely enough. The gap opens once volume or channel count grows past what one person can hold in their head. How to triage GitHub issues at scale and how to sort GitHub issues by something better than thumbs-up count cover that threshold in more depth.
Start today
Two changes take under ten minutes and help immediately. Uncheck "Automatically watch repositories" in your GitHub notification settings, then spend five minutes unwatching any repo you haven't touched in the last month. That alone shrinks the pile a real request has to survive. If the pile keeps growing regardless, or the requests you care about most are scattered across GitHub and two or three other tools, that's the signal to look at something that ranks by account instead of by arrival time.
