GitHub Slack Review Comments Not Showing? Fix Missing Alerts

You opened a pull request, a teammate left three inline comments, and your Slack channel shows nothing. The channel timeline is empty, so you assume the GitHub app dropped the notifications. Most of the time it didn't. The comments are either sitting in a thread under the PR's original message, hidden behind a subscription you never enabled, or stuck in a pending review that GitHub itself hasn't published yet.

This guide is for developers, engineering managers and Slack workspace admins using the official GitHub app for Slack with GitHub.com. It's a short troubleshooting path with literal commands and the result you should see after each one. Run them in order. The cheapest checks come first, and the most common cause (a missing subscription feature) comes before the most confusing one (the thread you haven't opened).

Remember this: a quiet channel timeline doesn't prove the comment was never delivered. Check the thread before you reconfigure anything.

Short answer: enable reviews and comments, then check the PR thread

Two things fix the large majority of cases where GitHub Slack review comments are not showing.

First, subscribe the channel to the review and comment features. Run this in the channel:

/github subscribe OWNER/REPO reviews comments

Replace OWNER/REPO with your repository, for example acme/api. Subscriptions are per repository and per channel, so a subscription in #backend does nothing for #frontend.

Second, open the thread on the PR's parent message in Slack. If you only watch the main channel timeline, thread replies are easy to miss, especially in a busy channel where the thread has no visible reply count.

If both of those check out and you still see nothing, the review is probably unpublished. A reviewer who adds inline comments but never clicks Submit review has a pending review, and GitHub doesn't send pending comments to anyone, Slack included. The pending-review section below gives you a two-minute test to confirm.

The five steps that follow walk through each check with the exact command and what a healthy result looks like. Don't skip to the end. Each step rules out one cause, and the order is built so you can stop as soon as something is fixed.

Step 1: Confirm the app is in the channel and you are signed in

The GitHub app can only post into channels it belongs to, and it can only show you activity from repositories your GitHub account can see. Both conditions fail quietly.

Start with channel membership. In the channel, type:

/invite @github

If the app is already there, Slack tells you the user is already in the channel. That's the result you want. If it was missing, Slack adds it and posts a join notice. For a private channel, you need to be a member yourself before you can invite anything.

Next, make sure your Slack identity is linked to GitHub:

/github signin

The app replies with a private (only-you) message. If you're already connected, it says so. If not, it gives you a Connect GitHub account button. Click it, finish the browser flow, and come back to Slack.

This matters for review comments because subscriptions are created by a signed-in user, and the app respects repository access. If the repo is private and the account that created the subscription lost access, or the GitHub organization hasn't approved the Slack app, events for that repo won't arrive. The same access logic is behind most private repository problems, which we cover in Fix GitHub Slack Private Repo Notifications.

Expected result after this step: the app is listed as a channel member, and /github signin confirms you're connected. If either still fails, stop here and resolve it before touching subscriptions. Nothing later will work without them.

Step 2: Check the current subscription with /github subscribe list

Before you add anything, look at what the channel is already subscribed to. Guessing at the current state is how people end up with duplicate subscriptions and conflicting settings.

Run this in the affected channel:

/github subscribe list

The app responds with a private message listing every repository this channel is subscribed to and which features are enabled for each. Read it line by line for your repo. A default subscription typically covers issues, pull requests, commits, releases and deployments. Reviews and comments aren't part of that default set.

That's the single most common reason review comments never appear. People subscribe to a repo, see the PR-opened message arrive, and assume everything about the PR is covered. The subscription is working exactly as configured. It was just never told to forward reviews or comments.

Three outcomes are possible:

• The repo is not listed at all. The channel has no subscription. Skip to Step 3 and create one.

• The repo is listed, but reviews and comments are absent. This is the usual case. Step 3 adds them.

• The repo is listed with reviews and comments already present. The subscription is fine. Go straight to Step 4 and inspect the thread, then the pending-review section for unpublished reviews.

Also check that you're in the right channel. Run the same command in any other channel where you expected the alerts. A subscription lives in exactly one channel, and teams often configure #eng-alerts while the PR conversation they're watching is in #eng-reviews.

Step 3: Enable reviews and comments (/github subscribe OWNER/REPO reviews comments) and what you should see

Now add the two features. In the channel, run:

/github subscribe OWNER/REPO reviews comments

For example, /github subscribe acme/api reviews comments.

You should see the app confirm the subscription update with a message naming the repository and the features now enabled. Run /github subscribe list again and confirm that reviews and comments now appear next to your repo. If the confirmation never arrives, go back to Step 1. The app is usually missing from the channel or you're not signed in.

Here's what each feature does, so you only turn on what you need:

• reviews forwards submitted pull request reviews: approved, changes requested, or commented-as-a-review.

• comments forwards comments on issues and pull requests, including the general conversation on the PR.

If you want to silence a feature later, the app supports /github unsubscribe OWNER/REPO reviews comments.

One caveat on timing. A subscription only affects events that happen after you create it. Comments left yesterday won't be replayed into Slack. To test, ask a teammate to submit a fresh review on a pull request, or submit one yourself on a test PR (GitHub doesn't let you approve your own PR, but you can submit a plain review comment). Then check Slack within a minute or so.

CI results on the same conversation are a separate concern. We cover the workflow-failure side in GitHub Actions Slack Notifications on Workflow Failure.

Step 4: Look in the PR's parent message thread before concluding nothing was delivered

This check saves the most wasted debugging. The official GitHub app documents threading: when a pull request is opened, the app posts a message to the channel, and later activity on that PR is attached as replies in that message's thread. The parent message can also update as the PR changes state.

So a review comment that was delivered perfectly won't appear in the main timeline. It appears one level down.

How to inspect it:

1. In the channel, scroll to the message the app posted when the PR was opened. Use Slack search with the PR title or number if the channel is busy.

2. Look under the message for a reply count (for example, "3 replies") and click it.

3. Read the thread panel. Review submissions and comments should be listed there, in order.

If the thread contains your comments, delivery worked and nothing needs fixing. What needs to change is where you look, or how your team is notified. A thread reply doesn't ping the channel, and people who aren't following the thread will see nothing. That's a visibility choice, not a bug.

If the parent message exists but the thread is empty, return to Step 3 and confirm reviews and comments are enabled, then test again with a new review. If there's no parent message at all, the PR was opened before the subscription existed, or the app wasn't in the channel at the time. Open a fresh PR to test a clean flow.

Don't conclude "Slack never got it" from a quiet timeline alone. Open the thread first, every time.

Step 5: Optional channel broadcast with comments:"CHANNEL" and reviews:"CHANNEL", and what /github settings controls

If your team wants review comments visible in the main channel instead of buried in threads, or sent to a different channel than the PR message itself, the app documents a channel-specific syntax. You attach a channel to a feature when you subscribe:

/github subscribe OWNER/REPO reviews:"#pr-reviews" comments:"#pr-reviews"

The quoted value is the destination channel for that feature. Use the exact syntax from the app's documentation, with the channel name quoted, and run /github subscribe list afterwards to confirm how the app recorded it. If the command is rejected, check that the app is a member of the destination channel. Step 1 applies to every channel you route into, not only the original one.

A practical note on whether you want this. Routing both features to a shared channel puts discussion in one place, but it also adds a visible message for every review and comment. On an active repo that adds up fast. Try it on one repo before applying it everywhere, and read How to stop GitHub and GitLab Slack notification spam if the channel starts getting noisy.

Now the point people trip on: /github settings. That command opens your personal and workspace-level preferences for the app, such as how your own notifications and account link behave. It doesn't decide which repository events a channel receives. Subscriptions and their features control channel delivery, and you manage those with /github subscribe. Changing /github settings won't make missing review comments appear, so don't spend time there while debugging.

Submitted review vs unpublished pending review: why a draft inline comment won't appear, and a quick test to confirm

If your subscription is correct and the thread is empty, the reviewer may simply not have finished. On GitHub, when someone clicks Add review comment on a diff line, GitHub starts a pending review. Those inline comments are visible only to the reviewer, with a yellow "Pending" label, until the reviewer clicks Finish your review and then Submit review. Using Add single comment instead of Start a review posts the comment immediately and would be delivered.

This catches people constantly, especially on big pull requests where a reviewer leaves 15 inline notes over an afternoon and then gets pulled into a meeting. From the author's side the PR looks untouched. From the reviewer's side the work is done. Slack is correct to stay quiet.

A two-minute test to confirm:

1. Ask the reviewer to open the PR, click Review changes at the top right of the Files changed tab, and look for a pending review banner or a count of pending comments.

2. Have them choose Comment, Approve or Request changes, then click Submit review.

3. Watch the PR's parent message thread in Slack. The review should appear there within moments, provided reviews is enabled.

If it appears, the whole pipeline works and the only issue was an unpublished review. If it still doesn't appear after a submitted review, return to Steps 1 to 3 and recheck sign-in, channel membership and subscription features, in that order.

Conclusion

Work the checklist in order: /invite @github, /github signin, /github subscribe list, then /github subscribe OWNER/REPO reviews comments, then open the PR thread, then confirm the review was actually submitted. Nine times out of ten the fix is one of the first four lines.

If you'd rather not hunt through threads at all, MergeMe puts each GitHub pull request in Slack as one updating card per PR. Start with the repo where reviews go missing most often.