Overwhelming Linear, GitHub, and Slack Notifications – What If 200 a Day Were 5?
Linear, GitHub, and Slack notifications overwhelming your engineering team? A teardown of why the architecture breaks – and the 5 signals worth keeping.
By Ellis Keane · 2026-03-13
The problem isn't that you get too many notifications. The problem is that you get exactly the right number – from three different tools, about the same event, at the same time.
Every webhook fires correctly. Every integration delivers precisely what it promised. GitHub notifies you about the PR. Linear notifies you about the issue the PR closes. Slack notifies you because someone, at some point (probably you, three months ago, in a burst of misplaced optimism about "visibility"), connected a bot to the project channel. Three tools, three notifications, one event, and all of them working exactly as designed. The engineering is immaculate. The experience is miserable.
Your Linear, GitHub, and Slack notifications aren't overwhelming because something is broken. They're overwhelming because nothing is. Each tool is faithfully executing its notification contract with zero awareness that the others exist. There is no shared event bus. There is no deduplication layer. There is no concept, anywhere in the stack, of "this human already knows about this." You're not suffering from a misconfiguration. You're suffering from the logical endpoint of plugging six tools into the same workflow and letting each one shout independently into the void.
"The notification system isn't failing. It's succeeding so hard it's burying you." – Chris Calo
Progress.
Anatomy of a single merge – the duplication autopsy
Let me walk you through one event – a single PR merge – and trace what happens in the notification layer. Not because it's unusual, but because it's depressingly ordinary.
A teammate merges a PR on GitHub. Here's the cascade:
- GitHub fires a webhook to your notification inbox. You authored a review on this PR, so you're subscribed. That's notification one.
- Linear's GitHub integration detects the linked issue and auto-transitions its status from "In Progress" to "Done." Linear generates a notification for everyone watching the issue – which includes you, because you're on the same team. That's notification two.
- The Slack bot (the one you connected in that fit of optimism I mentioned) posts a merge summary to #frontend. If anyone reacts to that message with an emoji or a comment, Slack generates a thread notification. That's notification three, potentially four.
- CI runs on the merge commit. GitHub fires another webhook. If CI passes, you probably don't care, but you're getting the notification anyway because GitHub's subscription model is binary – you're either watching or you're not. That's notification five.
Five notifications. One event. And you were on the call where the merge was discussed, so you already knew about it before any of them arrived.
Multiply this across every PR, every issue transition, and every CI run for a team of six, and you're looking at 30 to 40 duplicate events per person per day before you even count the genuinely new signals. The notification system isn't failing. It's succeeding so hard it's burying you.
Why muting is a patch on a haemorrhage
The standard advice is aggressive muting. Turn off GitHub email notifications. Set Slack to only notify on direct mentions. Unfollow all Linear issues except the ones assigned to you. This is the notification equivalent of treating a fractured wrist by taking off your watch – technically you've reduced wrist-related complexity, but you've also lost the ability to tell what time it is.
I tried the muting approach (of course I did – we all do, it's the first thing everyone tries, right before the second thing everyone tries, which is a Zapier chain that somehow makes it worse). I went aggressive: killed GitHub emails entirely, muted every Slack channel that wasn't my team's working channel, unfollowed everything in Linear except my own issues. Bliss for about three days.
Then I missed two blocking PR reviews because the discussions happened in channels I'd muted. The engineers who needed my review eventually DM'd me – which is just a notification with extra steps and a side of passive-aggressive "hey, did you see my message?" energy. A week later, a design decision landed in a Figma comment thread that completely changed the component I was halfway through building, and I didn't find out until my PR got rejected. Which was fun.
The fundamental problem with muting is that it applies static rules to dynamic context. Your notification settings from last Tuesday don't know about the urgent bug that landed this morning. And the more aggressively you mute, the wider the gaps in your awareness become – gaps that teammates fill with "just checking you saw..." DMs. Which, if you're keeping score, means aggressive muting doesn't reduce your notifications. It just shifts them from bots (who don't judge you) to humans (who definitely do).
The five signals that actually warrant interruption
After logging notifications for a few weeks (in a plain text file, because I'm exactly the kind of person you'd expect to be writing an article about notification architecture), a pattern emerged. Out of roughly 200 daily pings, the ones that genuinely required action within the hour fell into five categories:
- Someone is blocked by you. A PR review request on code you own, a question only you can answer, a decision waiting on your input. This is the only category where delay has a compounding cost – every hour you don't respond is an hour someone else can't work.
- Something you deployed is broken. CI failures on your branch, error spikes after your merge, a revert request. The "your code is on fire" category.
- A decision was made that affects your current work. A design change, an API contract update, a priority shift from the product side. These are rare but expensive to miss (see: my rejected PR, above).
- A deadline moved. Sprint scope changed, a demo got pulled forward, a dependency slipped. Calendar-altering events.
- Someone needs help and you're the right person. Not every @channel. Not every @here. The specific ones where your expertise is genuinely relevant – and even then, only if nobody else can answer.
Everything else – status transitions, automated bot messages, "sounds good" emoji reactions, CI passes on branches you're not watching – is information that might be useful eventually but does not need to interrupt the function you're writing. The notification industrial complex has convinced us that all of these deserve equal urgency. They don't.
Out of 200 daily notifications, roughly five categories actually warrant interrupting what you're doing. The rest are information that might be useful eventually – but the tools treat everything as equally urgent, which means nothing is.
A triage framework for the architecturally betrayed
Here's a framework you can start using today – no tools required, just discipline and about 20 minutes of setup. It won't fix the architectural problem (nothing short of a deduplication layer can do that), but it'll stop the bleeding while you evaluate longer-term solutions.
The twice-daily sweep: Instead of checking notifications continuously, batch them into two sweeps – once mid-morning, once mid-afternoon. During each sweep, scan your GitHub notifications, Linear inbox, and Slack unreads, and sort each into one of three buckets:
| Bucket | Rule | Action | |--------|------|--------| | Act now | Someone is blocked, something is broken, or a decision needs you | Handle immediately | | Batch | Important but not time-sensitive | Add to a "respond later" list, handle at end of day | | Archive | Bot chatter, status updates, resolved threads, duplicates | Mark as read, move on with your life |
Set channel-level defaults in Slack: For each channel, decide: is this an "act now" channel (your team's working channel, incident channels) or a "batch" channel (general announcements, cross-team updates)? Mute the batch channels and only check them during your sweeps. Yes, this is technically muting, which I just spent two paragraphs mocking – the difference is you're still checking them on a schedule rather than pretending they don't exist.
Use GitHub's notification filters: Bookmark github.com/notifications?query=reason:review-requested – that URL shows only PR reviews explicitly assigned to you, cutting out the subscribed/CI noise entirely. For email, GitHub includes a reason header (review_requested, mention, subscribed, ci_activity) that you can filter on: auto-archive "subscribed" and "ci_activity" and you'll lose nothing you actually need. The fact that GitHub buries this useful metadata in email headers rather than exposing it in the notification UI tells you everything about how much thought goes into the consumption side of these systems.
This approach won't catch the contextual signals (remember that Figma comment that torpedoed my PR? The twice-daily sweep wouldn't have caught that either). But it'll cut the noise by 60 to 70 percent, which is enough to stop the compulsive alt-tabbing while you figure out whether the problem warrants a real solution.
What a deduplication layer would actually need to do
This is where it gets architecturally interesting – and where I stopped thinking of this as a notification settings problem and started thinking of it as a classification problem.
The naive approach is keyword matching and mention detection. If your name appears, surface it. If it's a review request assigned to you, surface it. This catches the obvious cases but completely misses the contextual ones – the design decision in a thread nobody @-mentioned you in because they didn't realise you were building the component it affects. (That one's going to haunt me for a while.)
What you'd actually need is a graph of relationships: which tasks are yours, which PRs relate to which issues, which Slack threads are about which features, which people tend to need your input on what topics. When a new signal arrives – a Slack message, a GitHub event, a Linear transition – you classify it against that graph. Not "does this mention Chris?" but "does this affect something Chris is actively working on, waiting for, or responsible for?"
The classification would need to break into something like:
| Classification | What it means | Action | |---------------|---------------|--------| | Urgent | You're blocking someone, or something's broken | Surface immediately | | Important | Affects your current work, but not time-critical | Batch into a daily digest | | Informational | Good to know, no action needed | Available if you go looking | | Noise | Duplicates, bot chatter, resolved threads | Filtered out entirely |
The hard part is that classification confidence isn't binary. A Slack message in a channel you never visit might still be urgent if it references an issue assigned to you. A GitHub notification about a repo you haven't touched in months might matter if someone just reopened a bug you thought was fixed. You need two layers working in concert: an event normalisation layer that hashes each incoming webhook against a composite key – repo, issue ID, actor, event type – and checks it against a TTL'd dedup window (basically a sliding window of recent event fingerprints), and behind that, a live relationship graph mapping task ownership, PR linkages, thread participants, and recent activity patterns. You're essentially building a read model of the entire team's working state, updated in near-real-time, and querying it on every inbound signal. The dedup layer catches the obvious duplicates. The graph answers the harder question: "is this relevant to you specifically, right now?"
The core classification loop handles the clear cases well, and that alone cuts the noise substantially – but the genuinely ambiguous signals (where you're not confident enough to suppress but not confident enough to surface either) are still an open problem. We're experimenting with batching those into a "maybe" digest, but I won't pretend we've nailed it.
What changes when the firehose stops
The thing I didn't expect – I genuinely thought the benefit would just be "fewer pings" – is how profoundly your relationship with your tools changes when they stop screaming at you.
When every notification might be important, you develop this low-grade anxiety about unread counts. The Slack sidebar with its bold channel names. The GitHub bell. The Linear inbox. You check compulsively, not because you expect anything urgent, but because the cost of missing something feels higher than the cost of checking 50 things that turn out to be noise. I used to alt-tab to Slack between writing a function signature and its body. Not a conscious decision – just a reflex, the way you'd check your mirrors at a red light.
The preemptive self-interruption is arguably worse than the notifications themselves, because you're breaking your own concentration before any ping even arrives. You're living in a state of permanent partial attention, and you can feel it in the code you write – shallower reviews, safer architectural choices, the path of least resistance instead of the approach that's actually right, because you don't trust that you'll get 45 uninterrupted minutes to think it through.
When the firehose stops – when you trust that the important signals will find you and the noise won't – that reflex fades. Not immediately, because old habits are stubborn. But within a couple of weeks you notice that you're spending longer stretches in your editor without the compulsive alt-tab. You start finishing thoughts. You write better code, not because you suddenly became smarter, but because you stopped volunteering for 30 context switches an hour on behalf of a notification system that never asked you to.
Stop drowning in notifications. Sugarbug classifies every signal from Linear, GitHub, and Slack by relevance – and only surfaces what actually needs you.
Q: Does Sugarbug reduce overwhelming notifications from Linear, GitHub, and Slack? A: Yes. Sugarbug connects to Linear, GitHub, and Slack via API and classifies every signal by urgency and relevance. Instead of forwarding every notification, it surfaces only the ones that require your attention – typically reducing hundreds of daily pings to the handful that genuinely need you.
Q: Can Sugarbug prioritise GitHub PR notifications based on what I'm working on? A: Sugarbug builds a knowledge graph of your tasks, PRs, and conversations. It knows which PRs relate to your current work and surfaces review requests, merge conflicts, and CI failures for those first – while quietly filing away the rest.
Q: How is Sugarbug different from Slack's built-in notification settings? A: Slack's settings let you mute channels or set keywords, but they can't understand context across tools. Sugarbug reads across Linear, GitHub, and Slack together, so it knows that a Slack thread about a PR you authored is urgent even if it's in a channel you've muted.
Q: What's the real cost of notification overload for engineering teams? A: Gloria Mark's research at UC Irvine suggests it takes roughly 23 minutes to regain deep focus after an interruption. Beyond the pings themselves, the compulsive checking behaviour they create fragments the sustained concentration that complex engineering work demands.
If your engineering team notifications have crossed the line from "keeping informed" to "keeping anxious," that's probably a sign the architecture needs fixing, not your notification preferences.