GitHub Draft PR Slack Alerts: Ready for Review Checks

A teammate flips a draft pull request to Ready for review at 4:45 on a Friday. Did the channel hear about it, or did the PR sit there until Monday? Most teams assume yes and never test it. That assumption is how review requests quietly vanish.

The official GitHub Slack app can announce that moment, but only if the channel is subscribed correctly, and the alert it produces is easy to misread. A post in #code-review is not a review request. It assigns no one and pings no one. Engineering managers who treat it as a handoff end up with PRs everyone saw and nobody owned.

This guide gives you the short answer first, then a safe way to prove the behavior in a designated repo and channel, using only commands the GitHub app documents. You also get a checklist for when the alert never shows up. Think of it as a ten-minute audit you run once, write down, and stop worrying about.

Short answer: what the pulls subscription covers for draft to ready

Yes: the native GitHub Slack app's pulls subscription covers a draft pull request being marked Ready for review. When a channel is subscribed to a repository with pull request notifications on, that transition produces a post in the channel. You don't need a separate feature flag for it.

Here is the stance worth holding: that channel post is a broadcast, not a request. It tells the room a PR changed state. It doesn't tell any individual they owe a review.

The subscription is per channel and per repository. If #frontend-reviews is subscribed to acme/web and nobody subscribed #backend-reviews, a draft in acme/web becomes ready and only #frontend-reviews hears about it. The most common cause of "we never saw it" isn't a bug. It's a channel that was never subscribed to that repo.

Two more facts to keep in your head before testing:

• The feature is channel-scoped. Your DMs and your teammates' DMs are a separate matter entirely.

• The subscription is the source of truth. If the channel isn't subscribed, nothing posts, no matter how correctly the PR was flipped.

If you manage a team of 10 or 20 developers, write this down as a one-line team rule: a Ready for review post means the PR is open to the channel, and a named reviewer still has to be requested. The rest of this article shows you how to verify the post and how to keep the two ideas separate.

Channel alert vs CODEOWNERS assignment vs personal mention

Three different things get lumped together as "the review notification," and confusing them is where reviews fall through.

The channel alert. A message in a Slack channel because that channel subscribed to the repo's pull requests. Everyone in the channel can see it. No one is singled out. It exists for visibility.

The CODEOWNERS assignment. A GitHub-side mechanism. When a PR touches paths listed in a CODEOWNERS file, GitHub can automatically request review from the matching owners. That request is recorded on the pull request itself. Slack doesn't generate it, and the channel post doesn't create it. If you want to understand why those requests sometimes never reach Slack, see GitHub CODEOWNERS notifications in Slack: fix missing requests.

The personal mention. An @mention of a specific Slack user. That requires the GitHub identity to be tied to a Slack identity, and it only fires when something actually names that person, such as a requested review or a comment mentioning them. A channel post saying "PR is ready" mentions nobody.

A concrete before and after:

• Before: Priya marks #482 Add retry logic ready. #code-review gets a post. Six people see it. Each assumes someone else on the CODEOWNERS list will pick it up. Nobody does for nine hours.

• After: Priya marks it ready and requests two named reviewers. The channel still gets the broadcast, and the named reviewers also have a reason to act.

Never count the channel post as your assignment mechanism. Use it as the signal that the PR exists, and use reviewer requests or CODEOWNERS as the signal that a person owns it. MergeMe works from the same split, posting one updating card per PR in Slack so the channel view and the ownership question stay in one place, but the principle holds whichever tool you use.

Check what the channel is subscribed to (documented commands only)

Before you flip any draft, find out what the channel is actually subscribed to. The GitHub Slack app documents slash commands for this, so stick to those rather than guessing at features.

In the channel you want to audit, run:

/github subscribe list

That lists the repositories the channel is subscribed to and the features enabled for each. Find the repo you care about and confirm that pulls appears in its feature list. If the repo is missing, the channel isn't subscribed. If the repo is there but pulls isn't, pull request events aren't enabled for it.

To subscribe a channel to a repo's pull requests:

/github subscribe owner/repo pulls

To remove a feature, the documented counterpart is /github unsubscribe owner/repo pulls. Run /github subscribe list again afterward to confirm the state matches what you intended.

A few things to check while you're in there:

• Is the app installed on the repo's organization? An organization admin may need to approve or install the GitHub app for private repos. If you see nothing for a private repository, fix GitHub Slack private repo notifications walks through that case.

• Is the channel the one you think it is? Teams often have #code-review and #code-reviews, one letter apart. Run the command in the exact channel where you expect the alert.

• Is the repo name exact? Subscriptions are by owner/repo. A renamed or transferred repository is a different story, covered in GitHub Slack notifications after repository transfer.

Copy the /github subscribe list output into your team notes. It's your baseline. When something stops working in three months, you'll know what it looked like when it worked.

Run a safe draft-to-ready test in a designated repo and channel

Don't test in your busiest production channel. Pick a designated sandbox: a throwaway repository (or a low-traffic internal one) and a private test channel such as #pr-alert-test. The goal is to prove the behavior without paging anyone.

Setup (five minutes):

1. Create or choose the test repo. Confirm the GitHub Slack app has access to it.

2. In #pr-alert-test, run /github subscribe owner/test-repo pulls.

3. Run /github subscribe list and confirm pulls is listed for the test repo.

The test:

1. Create a branch and push a trivial change, such as a one-line edit to a README.

2. Open a pull request and choose Create draft pull request instead of the normal button.

3. Note what appears in #pr-alert-test while the PR is a draft. Write it down, even if it's nothing.

4. On the PR page, click Ready for review.

5. Watch the channel for a new post and note the timestamp against the moment you clicked.

6. Don't request any reviewers yet. You want to isolate the channel post from any assignment behavior.

Then run the control:

1. Request a review from a teammate (one who knows they're part of a test).

2. Check whether anything reaches that person beyond the channel post.

This two-stage structure is the whole point. Stage one shows what the channel broadcast does. Stage two shows what a named reviewer request adds. Seeing them separately, with your own eyes, settles the argument about what the alert means faster than any documentation.

When you finish, close the PR without merging and delete the branch. Leave the subscription in place if you plan to retest after configuration changes, or run /github unsubscribe owner/test-repo pulls to clean up. Record the results in a short note: date, repo, channel, what appeared at each step, and how long it took.

What to expect, and what pulls does not include

After running the test, you should see a post in the channel when the draft becomes ready. That's the confirmed behavior. Now be precise about the edges, because the subscription is narrower than people assume.

What you should expect:

• A channel-level post tied to the PR when it changes state, including the draft to ready transition.

• The post appears in the subscribed channel only, not in other channels and not in direct messages.

• No individual is notified by the post itself.

What the pulls subscription does not include:

• Reviews and review comments. Review activity is a separate feature in the GitHub app. A channel subscribed only to pulls won't show them. If review comments are missing for you, GitHub Slack review comments not showing: fix missing alerts covers it.

• Draft-only suppression. Don't expect the app to hold back notifications until a PR leaves draft. There's no documented "stay quiet until ready" switch in this subscription, so a draft can generate channel activity before it's ready. Plan for that rather than assuming drafts are silent.

• Personal notifications. Anything that pings you directly is governed by your own notification settings and identity linking, not by what the channel is subscribed to.

The practical consequence: if you want a clean channel where cards only appear once a PR is genuinely reviewable, the native subscription is a blunt tool for that. For the native app, the lesson is simple: test your own drafts and see what your channel really does. The answer is yours to observe, not to assume.

If no alert appears: delivery, Slack mute settings and reviewer assignment checks

You flipped the draft, waited a minute, and the channel is silent. Work through these in order. Each one takes under a minute.

1. Confirm the subscription. Run /github subscribe list in that exact channel. No repo listed, or no pulls for it, means you found the problem. Resubscribe with /github subscribe owner/repo pulls.

2. Confirm the app can see the repo. For private repositories, the GitHub app must be installed and authorized for the organization. An unauthorized app posts nothing and says nothing.

3. Confirm you flipped the right PR in the right repo. It sounds silly. It happens constantly, especially in monorepo-adjacent setups with several similarly named repositories.

4. Check Slack mute and notification settings. This is the most overlooked step. A message can post successfully and still never reach your eyes:

• The channel may be muted for you, so no badge and no sound.

• Your notification preference may be set to mentions only, which suppresses ordinary bot posts.

• Slack's do-not-disturb or a custom notification schedule may be active.

Open the channel and scroll. If the post is there, delivery worked and your settings hid it. That's a team habits problem, not a GitHub problem.

5. Check reviewer assignment separately. If a specific person expected to be told, remember the channel post never targets anyone. Verify a reviewer was actually requested on the PR, or that CODEOWNERS matched the changed paths. A PR touching files outside any CODEOWNERS pattern requests no one.

6. Check for reminders confusion. If what you actually wanted was a nudge hours later, that's a different mechanism. See GitHub Slack reminders not sending: checks and fixes.

If all six pass and the channel is still silent, rerun the sandbox test from the previous section. A clean failure in a controlled repo gives you something concrete to hand to your GitHub or Slack admin.

Related guides: CODEOWNERS requests and missing review comments

Draft-to-ready alerts are one slice of a larger question: who finds out, and how. Two neighboring problems come up right after this one.

Reviewer requests that never reach Slack. If a PR touches owned paths and the right people were never told, the gap is usually between GitHub's CODEOWNERS matching and Slack's delivery, not the draft transition. The guide on GitHub CODEOWNERS notifications in Slack walks through diagnosing it.

Review activity that goes missing. A subscription to pulls announces the PR. It doesn't carry reviews or comments. When approvals and review threads aren't appearing, the checks in GitHub Slack review comments not showing cover the feature flags and permissions involved.

If your team spans more than one code host, the same draft-to-ready question exists on the other side. The equivalent GitLab behavior is covered in GitLab draft merge request Slack notifications, and the differences between apps for mixed teams are laid out in GitHub Slack app comparison for mixed GitHub and GitLab teams.

A useful habit: after you finish the sandbox test, link your results note in your team's engineering handbook next to the review process doc. Then the next engineering manager who asks "will we see it when a draft goes ready?" gets an answer with a date on it instead of a guess. Treat notification behavior like any other infrastructure: observe it, write it down, and recheck it when something changes.

Conclusion

Run the sandbox test this week, and write down what appeared at each step. The result is a one-paragraph team rule: a Ready for review post in the channel is a broadcast, and a named reviewer request is what creates ownership. Keep those two things separate and drafts stop going stale on Fridays.

It shows each GitHub pull request in Slack as one card that updates in place from draft through review to merged, so the moment a draft becomes ready is a visible change on a card your team already knows.