Why GitHub's Slack Integration Doesn't Work for Most Teams

Every engineering team installs GitHub's Slack integration. Most of them end up working around it within weeks — manually pinging reviewers, copy-pasting PR links into DMs, or building custom bots.

This isn't a configuration problem. The integration's architecture makes the wrong tradeoffs for how most teams actually do code review.

The notification model is backwards

GitHub's Slack integration is event-driven: every PR opened, every comment, every commit push generates a webhook. The integration broadcasts these events to channels you configure.

The problem is that GitHub doesn't understand your team. It sees that Alice opened a PR and Bob commented on it. It doesn't know that Bob is the only person who understands that code, or that Alice is heads-down on a production incident and won't see the notification for hours.

So you get one of two outcomes: everyone gets notified about everything (noise), or notifications are filtered so aggressively that people miss things they need to act on.

A thread on r/ExperiencedDevs captures this well — developers describe asking 5+ people to review because they can't tell who's available, reviews getting dismissed on push, and teammates leaving "LGTM" comments without approving because approving triggers more notifications when changes are made.

It requests too many permissions

To use GitHub's Slack integration, you grant it:

• Read access to actions, commit statuses, checks, discussions, issues, metadata, pull requests, and repository projects
• Write access to actions, issues, deployments, and pull requests
• Access to your organization membership
• Permission to post messages as the app

This isn't a notification tool — it's a GitHub client living inside Slack. Most teams just want "tell the right person when they need to review something."

Enterprise features, small-team reality

The integration ships with branch filtering, label-based event filtering, scheduled reminders, configurable threading models, and deployment approval workflows. These solve real problems for large organizations with dedicated DevOps teams.

For a 5-person startup, they're configuration overhead that doesn't address the core issue: getting the right notification to the right person at the right time.

A post on r/webdev describes a developer who built a custom Slack bot because their team's review speed kept coming up in retros. The problem wasn't that GitHub couldn't notify people — it's that the notifications weren't actionable.

What teams actually need

When you strip away the enterprise features, developers need exactly three notifications about pull requests:

1. "You need to review this." Someone opened a PR and you're assigned. You need the PR title, the diff size, and a link. That's it.

2. "Your review is done." Someone reviewed your PR. Was it approved? Changes requested? You need to know so you can act on it.

3. "Something changed on a PR you care about." New commits pushed, conflicts detected, CI failed. But only for PRs you're actively involved in — not every repo you've ever starred.

Everything else is noise. No threading debates, no webhook filter configuration, no deployment approval workflows.

A different approach

Tenpace is built around this simpler model. Instead of broadcasting repository events to channels, it routes notifications to specific people based on who's likely to act on them.

One Slack message per PR. Status updates edit in place instead of creating new messages. Reviewers get @mentioned directly. No channel spam.

It takes about three minutes to set up — install the GitHub App, authorize Slack, link your team members. The notification routing works from there.

We're in early beta and it's free to use. If your team's PR communication involves more DMs than automated notifications, give it a try.

Questions or feedback? hello@tenpace.com