How to Integrate GitHub With Slack: The Complete 2026 Guide

By Fahad Ijaz · May 8, 2026 · Updated 2026-07-08 · 11 min read

Connecting GitHub to Slack takes about five minutes. Making that connection genuinely useful, instead of a firehose everyone eventually mutes, takes a few more decisions. This guide covers both: the exact steps to install the GitHub Slack integration, every command worth knowing, how to choose which notifications land in which channel, and what to do once the raw event stream stops serving anyone outside engineering.

How to connect GitHub to Slack (step by step)

The official GitHub app for Slack is free and installs in minutes. You need permission to add an app to your Slack workspace, and for private repositories, someone with admin rights on the GitHub organisation has to approve access. Here is the full setup:

• Open the Slack channel you want GitHub notifications in (for example, [#team-checkout]).
• Type the subscribe command below and press enter. Slack will prompt you to connect and authorize your GitHub account the first time.
• Approve the GitHub authorization in the browser tab that opens. For private repos, an org owner approves the install once.
• Confirm the subscription. GitHub posts a confirmation message listing exactly what the channel is now subscribed to.

/github subscribe owner/repo

# examples
/github subscribe acme/web-app
/github subscribe acme/web-app issues,pulls,releases
/github subscribe list          # show this channel's subscriptions
/github unsubscribe acme/web-app # stop notifications for a repo

That is the entire setup. The same GitHub-to-Slack connection works per channel, so you can subscribe #product to releases only while #eng-backend gets pull requests and deployments. Repeat the subscribe command in each channel with the event types that channel actually cares about.

Choosing which GitHub notifications to send to Slack

By default a subscription turns on several event types at once, which is the number one reason GitHub-Slack channels get muted in week one. Turn features on and off explicitly so each channel shows only what its audience needs. This table lists the notification types you can toggle:

Toggle any feature per channel without unsubscribing the whole repo. To quiet a busy channel, turn off the noisy features rather than muting the channel outright:

# add only what you want
/github subscribe acme/web-app reviews,comments

# remove the noisy stuff
/github unsubscribe acme/web-app commits,branches

# filter pull requests by label
/github subscribe acme/web-app pulls +label:"customer-facing"

GitHub to Slack command cheat sheet

Almost everything you will ever need runs through the /github slash command. Keep this reference handy:

A channel strategy that scales past five repos

Two patterns work, and mixing them is where teams go wrong. Per-repo channels (#repo-web, #repo-api) keep noise contained but force people to remember which channel maps to which service. Per-team channels (#team-checkout, #team-growth) match how people actually think about work but blend events from several repos. The team-channel approach scales better once you pass roughly five repositories, as long as each channel subscribes to only the two or three event types its members act on.

• Keep a dedicated channel for deployment and security alerts so they never get buried under routine pull request chatter.
• Subscribe cross-functional channels (#product, #support) to releases only, never to commits or branches.
• Use label filters so a channel sees, for example, only customer-facing or incident-tagged pull requests.
• Review subscriptions quarterly with /github subscribe list and prune anything nobody reacts to.

Troubleshooting the GitHub Slack integration

Most problems come from permissions or over-subscription rather than the integration itself. The usual fixes:

• No notifications appearing: run /github subscribe list to confirm the channel is actually subscribed, and check that an org owner approved access for private repos.
• Cannot subscribe to a private repo: the GitHub organisation owner needs to approve the app install and grant repository access before subscriptions work.
• Too many messages: unsubscribe the noisy features (commits, branches, comments) instead of muting, so the signal survives.
• Wrong account connected: run /github signout, then /github signin, and authorize the correct GitHub account.

GitHub Slack bot vs a codebase Q&A bot

The native GitHub app is a notification pipe: it broadcasts events to people who already read code. The moment product managers, support, and new hires start asking what a change means, you need a different kind of GitHub Slack bot, one that answers questions instead of forwarding events. Here is the honest split:

They are complementary. Keep the native app for engineering channels that genuinely want the event stream, and add a question-answering layer for the #product, #support, and #onboarding channels where the audience cannot read a diff. See how the Figorit Slack integration and GitHub integration connect in one place.

Give non-engineers a GitHub Slack bot they can actually use

Once the technical channels are humming, the next request is always some version of: can we get this for the product team? Raw GitHub events will not help them, the messages are too low-level. A codebase-grounded bot reads the same repositories and answers in plain English, with citations to the exact files. Ask it whether a feature shipped, what changed in an area this week, or who owns a service, and it responds in seconds without pulling an engineer out of flow. This is what that looks like in Slack:

Same source of truth as the native integration, a completely different output: answers a PM, support lead, or new hire can act on. If your #github-activity channel is muted by everyone except a bot, that is the layer you are missing.

Written by Fahad Ijaz. About Figorit.