How to post GitHub releases to Slack
Three real ways to post GitHub releases to Slack: the official GitHub Slack app, a raw incoming webhook with curl, and GitHub Actions with slack-github-action - plus the honest limit that leads to a release-marketing tool.
What this solves
A developer wants their GitHub releases to post into a Slack channel and is deciding between GitHub's own Slack app, a raw webhook, or a GitHub Actions workflow.
How S2P helps
Three working recipes for getting GitHub releases into Slack, a comparison of setup effort and control, and the honest limit that these paths only reach your own workspace.
Key takeaways
- GitHub's own Slack app is the fastest path: one slash command subscribes a channel to releases only.
- A raw Slack incoming webhook needs no OAuth and works with a single curl POST.
- GitHub Actions with slack-github-action gives you the most formatting control inside your existing CI.
- All three paths notify your team in your Slack workspace - none of them reach your users or a public channel.
Section 1
The fastest path: GitHub's own Slack app
GitHub ships an official Slack app built for exactly this job. If you just want releases to show up in a channel, start here.
GitHub and Slack maintain an official integration app (github.com/integrations/slack) that connects a GitHub repository, organization, or team to a Slack workspace with slash commands, no custom code required. A Slack admin installs it once from the Slack App Directory, and after that, anyone with access to the repo can run /github subscribe owner/repo in the channel where they want release activity to appear.
A plain subscribe links several event types by default, not only releases. To narrow a channel down to releases only, subscribe and then unsubscribe the defaults you do not want. Running /github subscribe owner/repo releases turns on release notifications for that repository in that channel; running /github unsubscribe owner/repo issues pulls commits turns the other default event types back off, leaving a clean releases-only feed.
This path needs a Slack workspace admin to approve the app install once, and after that any team member with GitHub access to the repo can run the subscribe command in any channel. It is the right default for an internal engineering or release channel, and it works for private repositories as long as the person running the command can see the repo on GitHub.
- Install the official app once per Slack workspace (needs admin approval).
- /github subscribe owner/repo releases links a repo and turns on release notifications.
- /github unsubscribe owner/repo issues pulls commits turns off the other default event types.
- Works for private repos if the person running the command has GitHub access to them.
Subscribe a Slack channel to releases only
/github subscribe owner/repo releases
/github unsubscribe owner/repo issues pulls commitsSection 2
Recipe 2: a raw Slack incoming webhook
If you want full control over the message format and do not want to depend on GitHub's own app, a plain Slack incoming webhook is a single POST away.
Create a Slack app for your workspace (or reuse one you already have), add the incoming-webhook scope under OAuth & Permissions, install the app to your workspace, and pick a channel to post to from the Incoming Webhooks page in the app's settings. Slack gives you a unique URL that looks like https://hooks.slack.com/services/T000/B000/XXXX - store it as a secret, because anyone with the URL can post a message into that channel.
Posting is then a single HTTP POST with a JSON body. The minimal payload is a text field; Slack also supports Block Kit blocks for a richer, formatted message with a title, a description, and a link. Test the URL from your terminal before wiring it into anything - if the curl command below posts a message, the webhook is good.
You own the trigger for this recipe: call it from a backend that already hears about your GitHub releases, or fire it from a GitHub Actions workflow, which is recipe 3 below and the most common way to call this same webhook automatically the moment a release publishes.
- Create the webhook under a Slack app's Incoming Webhooks page; needs a Slack admin to install the app once.
- The URL accepts a JSON POST with a text field, or richer Block Kit blocks.
- Treat the URL as a secret - anyone who has it can post to that channel.
- You own the trigger: call it from a script, a backend, or CI.
Minimal Slack webhook test (curl)
curl -sS -X POST "https://hooks.slack.com/services/T000/B000/XXXX" \
-H "Content-Type: application/json" \
-d '{
"text": "Released v2.4.0: Approval rules now route releases to the right reviewer. <https://github.com/your-org/your-repo/releases/tag/v2.4.0|View release>"
}'Section 3
Recipe 3: GitHub Actions with slack-github-action
If you want the release-to-Slack trigger to live next to your code, Slack's own GitHub Action wires a release event straight to an incoming webhook.
slackapi/slack-github-action is Slack's official GitHub Action for posting to Slack from a workflow. Configured with webhook-type: incoming-webhook, its three inputs are webhook (the URL from recipe 2), webhook-type, and payload (plain text or Block Kit, written as YAML). Trigger the workflow on release: types: [published] so it only fires when a release actually goes live, not on drafts or edits.
Store the webhook URL as a repository secret and reference the release event's fields - name, tag, and URL - straight from the github.event.release context. This gives you everything the raw webhook recipe does, but the trigger, the payload shape, and the secret reference all live inside your repository's version-controlled workflow file instead of a separate backend.
- Triggers only on release: types: [published], not drafts or edits.
- webhook, webhook-type: incoming-webhook, and payload are the three inputs the action needs.
- The webhook URL is the same one from the raw-webhook recipe - store it as a repo secret.
- Everything is versioned in your workflow file, not in a separate backend.
.github/workflows/slack-on-release.yml
name: Post release to Slack
on:
release:
types: [published]
jobs:
notify:
runs-on: ubuntu-latest
steps:
- name: Post to Slack
uses: slackapi/slack-github-action@v4.0.0
with:
webhook: ${{ secrets.SLACK_WEBHOOK_URL }}
webhook-type: incoming-webhook
payload: |
text: "Released ${{ github.event.release.tag_name }}: ${{ github.event.release.name }}"
blocks:
- type: "section"
text:
type: "mrkdwn"
text: "Released *${{ github.event.release.tag_name }}*: ${{ github.event.release.name }}\n<${{ github.event.release.html_url }}|View release>"Section 4
Which path should you use?
All three recipes above end with a message in a Slack channel. They differ in setup time, who has to be involved, and how much you can control the format.
If you just want releases visible to your team with zero maintenance, the GitHub Slack app's subscribe command is the least amount of work and the least you will ever touch again. If you want a specific message format, or you want the trigger and the payload versioned with your code, the raw webhook or the GitHub Actions recipe give you that control at the cost of a small amount of setup.
- GitHub Slack app: fastest, least control, zero code.
- Raw webhook: most control, needs a trigger you build or call from somewhere.
- GitHub Actions: same control as the raw webhook, but versioned with your repo.
- All three need a Slack admin to install the app or create the webhook exactly once.
GitHub-to-Slack paths compared
| Path | Setup time | Needs a Slack admin | Formatting control | Works for private repos | Who receives it |
|---|---|---|---|---|---|
| GitHub Slack app | Minutes | Yes, once (app install) | Low - fixed message format | Yes | Everyone in the channel |
| Raw Slack webhook | ~15 minutes | Yes, once (app install) | High - plain text or Block Kit | Yes - you control the trigger | Everyone in the channel |
| GitHub Actions + slack-github-action | ~15-30 minutes | Yes, once (app install) | High - same as raw webhook, versioned in CI | Yes | Everyone in the channel |
Section 5
What none of these reach: your users
All three paths above share the same honest limit, and it is worth stating plainly before you pick one.
The GitHub Slack app, a raw incoming webhook, and a GitHub Actions workflow all do the same job: they notify a Slack channel inside your own workspace. That is genuinely useful for your team - engineering, support, and anyone who needs to know the moment something ships. None of them reach your users, your customers, or a public audience, because a Slack incoming webhook can only post into the workspace that created it.
If the release also needs to reach people who are not in your Slack - a changelog readership, X, LinkedIn, a public Discord, Bluesky - that is a separate problem with a separate set of tools, and it is the gap S2P is built to fill: one GitHub release becomes drafted, channel-native posts for the public channels you connect (LinkedIn, X, Threads, Bluesky, Reddit, Mastodon, Discord, and more), reviewed and approved before anything publishes, running alongside - not instead of - your internal Slack notification.
For a deeper comparison of GitHub Actions, raw webhooks, and a purpose-built tool across auth, retries, approvals, and cost, see our GitHub Actions vs webhooks breakdown - it covers the general trade-off in full where this page stays specific to Slack.
- A Slack webhook can only post into the workspace that created it - it cannot reach your users.
- All three recipes above are for your team, not your audience.
- Public, multi-channel release announcements are a different job (see the linked comparison).
- S2P runs alongside your internal Slack notification, not instead of it.
FAQ
Questions this article answers
How do I post GitHub releases to a Slack channel?
The fastest way is GitHub's own Slack app: a Slack admin installs it once from the Slack App Directory, then anyone with repo access runs /github subscribe owner/repo releases in the target channel. If you want more control over the message format, use a raw Slack incoming webhook (a single curl POST) or a GitHub Actions workflow using slackapi/slack-github-action triggered on release: types: [published].
How do I subscribe a Slack channel to GitHub releases only?
Run /github subscribe owner/repo releases in the channel. A plain subscribe also turns on issues, pulls, and commits by default, so follow it with /github unsubscribe owner/repo issues pulls commits to leave only release notifications active in that channel.
What are the inputs for slackapi/slack-github-action?
The action takes three inputs when posting through an incoming webhook: webhook (the Slack webhook URL, stored as a secret), webhook-type set to incoming-webhook, and payload, written as YAML containing a text field and optional Block Kit blocks. Use v4.0.0 or later of the action.
Do I need a Slack admin to set this up?
Yes, once. Whether you use the official GitHub Slack app or create a raw incoming webhook, a Slack workspace admin has to approve the app installation a single time. After that, subscribing additional channels or repos with /github subscribe does not require admin involvement again.
Can a Slack webhook post GitHub releases to my users, not just my team?
No. A Slack incoming webhook can only post into the Slack workspace that created it, so all three recipes on this page notify your own team, never your users or the public. Reaching users needs a different destination entirely - a changelog, X, LinkedIn, a public Discord - which is a separate publishing job.
What is the difference between the GitHub Slack app and a raw Slack webhook?
The GitHub Slack app is faster to set up and needs no code, but the message format is fixed. A raw Slack incoming webhook (used directly or from a GitHub Actions workflow) takes a few more minutes to configure but gives you full control over the message text and Block Kit formatting, and keeps the trigger logic versioned in your own code.
Related guides and pages
Where to go next
Hand-picked pages that go deeper on the workflow, channels, and tooling covered above.
