GitHub Slack digest: events, digests and briefings compared

A GitHub Slack digest fixes part of the problem. A channel that posts every open, review and merge is built for reviewers, so everyone else mutes it. The fix is to route by audience: reviewers get events, the team gets a daily digest of merges and open blockers, and the leader gets a short briefing of decisions and exceptions.

What happens when everyone mutes #github?

You set up the GitHub app in Slack a while ago. Every PR open, review request, comment and merge lands in #github. For the first week people watched it. Now it scrolls past, and everyone has muted it.

Then, in a Monday meeting, someone from design says, "I didn't know that shipped." It merged the previous Wednesday. The event was in the channel, between a CI notice and two review comments. Nobody saw it because nobody had read that channel in weeks.

The channel did its job. It posted every event. That is also why it failed.

Why does a GitHub channel turn into noise?

An event stream grows with the number of PRs, and each PR produces several events. When a team ships at human speed, that is tolerable. When agents open PRs all day, it is not. Context is created faster than people can read it, and a feed that tries to carry all of it carries none of it. That is the core problem we write about: AI-native teams generate context faster than humans can sync, manage or remember it, and routines built for human-speed change stop working.

Here is what that looks like on our own team. In Biddle's data, merged PRs across the repositories we track, from live webhooks, were 15, 23, 21 and 12 on the weekdays from September 29 to October 2, 2026 (Pacific time). A channel posting opens, reviews and merges for those PRs would post several messages per PR, and those counts are merges only. The merge that matters is a small fraction of them.

The cost is plain:

• People stop reading, so they miss the one merge that changed what they are working on.
• Someone reassembles the picture by hand: scrolling, opening PRs, asking in a thread.
• Decisions get reopened because the merge that implemented them went unnoticed.

What do teams usually try?

Each common fix is good at something. The trouble is that each one serves one audience, and the channel serves everyone.

A digest is the right instinct, and most of the tools above get you there. What they do not do is connect a merge to the thread where the team decided it. For that you need the third level.

How do you route GitHub updates by audience?

Three levels, each with a different reader and a different rule about what is allowed in. You can set this up this week.

Level 1: events go to the people who act on them

Reviewers need events, and only reviewers.

1. Narrow the GitHub app's subscription in the shared channel to what the channel needs (for example pull requests and reviews) and drop the rest. The app generally lets you choose which event types a channel receives.
2. Ask reviewers to rely on review-request notifications, per-PR threads or direct messages rather than a team-wide feed.
3. Keep #github if you want an archive, but stop treating it as the place where people learn what shipped. Say so in the channel description.

The goal is not silence. It is that the people who must react to an event still see it, and nobody else has to.

Level 2: the team gets a daily digest of merges and open blockers

The team needs to know what changed, once a day, in a message short enough to read.

1. Pick one owner for the digest. A digest nobody owns decays into another feed.
2. Schedule it for weekday mornings. A scheduled GitHub Actions workflow that queries the PRs merged in the last 24 hours and posts to a Slack incoming webhook is enough. A no-code tool does the same.
3. Filter hard. Include only merged PRs, plus open blockers: PRs waiting on review longer than a limit you set, and anything marked blocked. Leave out opens, comments, bot noise and CI chatter.
4. Require one plain sentence per item. If your PR titles say "fix stuff", the digest will too, so make the PR title say what changed for a user or for the plan.
5. Link each item to the PR, and to the Slack thread if there was a decision behind it. Add that thread link to the PR description at merge time.

An illustration with sample data of what the digest should look like:

Merged since yesterday (3)
- Checkout: switch saved cards to the new payment flow (PR link) - decided in the pricing thread (thread link)
- Onboarding: remove the skip button on step 2 (PR link)
- Settings: rename Workspace to Team in all labels (PR link)
 
Open blockers (2)
- Export to CSV: waiting on review for 2 days (PR link)
- Auth refresh: blocked on a product question (thread link)

The test for a good digest is that someone from design can skim it and say right away whether anything affects them.

Level 3: the leader gets decisions and exceptions

The leader does not need the list of merges. The leader needs to know what needs a decision, what changed that may contradict what the team agreed, and what is worth a look. Say 40 PRs merged while you were out: you do not want 40 lines. You want the handful that need you.

By hand, plan on a short, fixed block each weekday morning:

1. Read the digest from Level 2.
2. Scan the Slack threads where decisions were made since the last time you looked.
3. Write three short lists: Needs you (open decisions and blocked work waiting on you), Since last briefing (what changed, with links), and Worth a look (merges that may not match a decision).
4. For each item, link the PR or the thread. An item without a link is a guess.

We use the same three headings in our daily status update template. Level 3 is the hardest to keep up by hand, because it means reading across Slack and GitHub at the same time.

Two rules keep all three levels honest:

• Each message has one audience. If you cannot say who it is for, do not post it.
• Every item links to its evidence. A summary without a link is an opinion.

Where does Biddle fit?

Biddle is the third level. It is an AI chief of staff for product teams that reads GitHub (PRs, reviews, CI and a diff excerpt) and the Slack channels it is invited to, and it sends the leader a weekday morning briefing with Needs you, Since last briefing and Worth a look, plus a team briefing in #askbiddle. It is read-only on GitHub and does not post into your #github channel; you can see what it reads and keeps in the home page section on data. On the Slack side, who sees what in an AI answer explains how private channels stay private. It is in early access and runs every weekday for our own team. Member notes are written and reviewed but not yet sent, and GitHub and Slack are the only sources today (Linear and Notion are coming, not integrated). If you want to see how a briefing differs from a digest, look at the sample briefing.

Common questions

Should we delete the #github channel?

Not necessarily. It is a fine archive and a useful place for reviewers. Stop expecting it to tell the rest of the team what shipped.

Can a digest replace review notifications?

No. A daily digest is too slow for a PR waiting on a reviewer. Keep review requests as direct notifications and use the digest for everyone else.

Does Biddle post in a team's #github channel?

No. Biddle posts only in DMs, in its own #askbiddle channel, and in threads where someone asks it a question.

Read next

• Too many PRs to review? What to track when agents ship 200+ in two weeks: what to track when the volume makes reading every PR impossible.
• Keeping an AI-native product team on the same page: a shared record and weekly rhythm that sits above any channel.
• Decisions lost in Slack threads: a decision log template: a way to link merges back to the threads where decisions were made.