Send a Slack notification when a PR is ready for review

Review channels get muted for one reason: they fire too early. Someone opens a draft to run CI, pushes six times, and the channel lights up for every one of them. The fix is to notify on a single moment, when the PR leaves draft and is ready for a human, and stay quiet the rest of the time. This post builds that with a filtered GitHub Action, then walks through the cases where a one-event filter quietly does the wrong thing.

Why the default integration pings on drafts

The official GitHub + Slack app subscribes a channel to a repo's pulls feed, which the app documents as covering PR changes and draft PRs marked ready. In practice that means a work-in-progress draft still generates channel activity, and there's no built-in "ready only" switch. If your team opens draft PRs early (a good habit for CI and visibility), the channel pays for it, and people mute it. Once it's muted, the one notification that mattered, "this is ready for you," goes unseen.

GitHub gives you a precise hook for exactly this moment. The pull_request webhook and workflow event has a ready_for_review action that fires when a pull request transitions out of draft. Filter on that and the noise problem largely goes away.

The DIY version: filter on ready_for_review

Store your Slack incoming webhook URL as a repository secret named SLACK_WEBHOOK_URL, then add .github/workflows/ready-for-review.yml:

name: Ready-for-review ping
on:
  pull_request:
    types: [opened, ready_for_review]

jobs:
  notify:
    # ready_for_review is always non-draft; this also filters out
    # PRs that are *opened* directly as drafts.
    if: github.event.pull_request.draft == false
    runs-on: ubuntu-latest
    steps:
      - name: Post to Slack
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
          PR_URL: ${{ github.event.pull_request.html_url }}
          PR_TITLE: ${{ github.event.pull_request.title }}
          PR_NUM: ${{ github.event.pull_request.number }}
        run: |
          payload=$(jq -n \
            --arg text "Ready for review: <${PR_URL}|#${PR_NUM} ${PR_TITLE}>" \
            '{text: $text}')
          curl -sS -X POST -H 'Content-type: application/json' \
            --data "$payload" "$SLACK_WEBHOOK_URL"

Two events, one guard. Subscribing to opened catches PRs that are created in the ready state, and ready_for_review catches the draft-to-ready transition; the draft == false job condition means an opened draft posts nothing. Using jq -n to build the JSON keeps the PR title safe even when it contains quotes or backticks, which a naive string interpolation into curl would break on.

Where filtering on one event breaks

The trigger is correct. The trouble is that "ready for review" is a moment, and a review is a loop.

Changes-requested doesn't re-notify. A reviewer asks for changes, the author pushes fixes and wants another look, but the PR was never a draft during that round, so no ready_for_review fires. The channel stays silent on the re-review, which is often the ping people most want. Covering it means also handling the review_requested action, and now you're maintaining two notification paths with different payloads.

Draft ping-pong double-fires. Convert to draft, convert back to ready, and ready_for_review fires again, so a PR that bounced states pings twice. Guarding against that needs state you don't have in a stateless workflow.

Every ping is a new, standalone message. A Slack incoming webhook can only create messages, not edit or thread them (Slack's docs note incoming webhooks do not allow you to delete a message). So the "ready" ping, any later re-review ping, the eventual merge, and the CI result are all separate posts scattered down the channel instead of one message that tells the PR's story.

No CI status. "Ready for review" doesn't mean "the pipeline passed." To show that, you correlate a separate check_suite or status event with this PR and edit the original message, which a webhook can't do. That's a bot token, chat.update, and stored message timestamps, in other words a small service.

Per-repo sprawl. This file lives in each repo. Ten repos means ten copies to keep in sync, and the same secret configured ten times. Org-wide behavior wants org-level tooling.

Build it or skip it?

• Ship the workflow if a single "it's ready" ping per PR is all you need. It's a real improvement over the draft-noisy default and costs nothing.
• Add review_requested if re-review pings matter, and accept that you now maintain two paths.
• Use a maintained tool once you want one message per PR that carries the ready state, CI status, and review comments together instead of scattered posts.

The mirror image of this problem, reminding reviewers about PRs that went quiet, is covered in automatic Slack reminders for GitHub pull requests. If you're on GitLab, the terminology and the native options differ; start with merge request vs pull request and every way to connect GitLab and Slack.

Bottom line

Filtering on ready_for_review plus a draft == false guard is the correct fix for draft noise, and for many teams it's enough on its own. Just know its edges: it says nothing on a re-review, it can double-fire on draft ping-pong, and every notification is a separate message with no CI context. Ship the workflow, add review_requested if you need it, and move to a maintained tool when you want the whole PR in one updating message instead of a trail of pings.