How to connect GitHub to Slack: 3 methods, and when to use each
Three ways: the official GitHub app for Slack (fastest setup, per-event notifications), GitHub Actions with a webhook (full control, maintenance on you), or a digest tool like HotBot (one filtered daily summary). Rule of thumb: quiet repos, native app; busy repos, digest.
Method 1: the official GitHub app for Slack
Install from slack.com/apps (search GitHub), authorize GitHub, then run /github subscribe owner/repo in the channel you want. You can subscribe to a subset of events: PRs, issues, deployments, reviews. Setup takes minutes. The trade-off is granularity: you get a message per event, so an active team produces a noisy channel fast. Muting the channel is the usual next step, which defeats the purpose.
Method 2: GitHub Actions with a Slack webhook
Create an incoming webhook in Slack, store the URL as a repository secret, and add a job (or use a community action) that posts when workflows finish. This is the right tool for CI-only alerts: build failed, deploy done. You control exactly which jobs post and what the message says. The trade-off: you own the YAML forever, and PR review activity - the thing reviewers actually need - is not covered.
Method 3: a digest bot like HotBot
Connect your repositories read-only, pick a channel and a schedule, and get one filtered daily summary: open PRs, CI results, review status, plus escalation for PRs sitting too long. Drafts, WIP, and bot PRs are filtered out before posting. The trade-off: notifications are not real-time, so on-call alerts still belong in a separate pipeline.
Which should you pick?
Under roughly ten PR events a day, the native app is fine. If you only need CI results in a deploys channel, use Actions with a webhook. If your GitHub channel has been muted by half the team, that is the signal to switch to a digest - the channel stays useful because it only speaks when there is something to review.
How do I stop the GitHub spam in an existing Slack channel?
Three levers: /github unsubscribe from the events you do not read, move GitHub traffic to a dedicated low-priority channel, or replace per-event posting with a digest. Muting the channel alone hides the useful messages along with the spam.