The median time from PR creation to first reviewer comment is 15 hours, according to Microsoft Research data. For most teams, the notification setup is doing a surprising amount of that damage.
When a PR card lands in Slack, the assigned reviewer sees their GitHub username as plain text. There is no mapping to Slack handles, so notifications get missed and review times stretch. That one gap-GitHub username vs. Slack handle-is arguably the most common reason a PR sits untouched while the author pings people manually.
This post is about the specific things the GitHub Slack integration does and does not do, the commands worth knowing, where the official app genuinely breaks down at team scale, and what to do about it.
What the GitHub Slack integration actually does
A GitHub Slack integration connects GitHub events - pull requests, reviews, issues, commits, releases, deployments, checks, and GitHub Actions workflows - to Slack channels or direct messages.
The official app, built and maintained by GitHub, handles this with /github subscribe commands you run inside a channel.
A basic integration reports activity. A more specialized pull request integration can route updates to specific reviewers, send reminders, synchronize comments, or create a separate collaboration space for each PR. The practical distinction is notification versus workflow.
Knowing what the official app does and does not subscribe you to by default matters more than most teams realize.
The following notifications are enabled by default: deployments - deployment review notifications and deployment status updates. Reviews and comments are disabled by default and need to be enabled by the user.
So out of the box, your #eng channel hears about deployments and new PRs, but not the review activity that tells your team a PR is approved or stuck. Most teams discover this six months in, when they notice that review threads are happening inside GitHub and nobody in Slack knows a PR is ready to merge.
The fix is one command: