GitHub + Slack: release notes and updates done for you
Release day shouldn’t feel like archaeology. But somehow you’re always digging through merged PRs, guessing what shipped, and then rushing a Slack message that’s missing the one change someone actually cares about.
This GitHub Slack release automation hits DevOps engineers hardest, honestly. Product-minded engineering leads feel it too, and so do technical writers who get pulled in at the last minute. The outcome is simple: draft release notes that stay consistent, plus a ready-to-send Slack update, without the manual scramble.
You’ll see how this n8n workflow pulls merged PRs since the last tag, turns them into structured notes, creates a draft GitHub release, then posts a clean summary to Slack.
How This Automation Works
Here’s the complete workflow you’ll be setting up:
n8n Workflow Template: GitHub + Slack: release notes and updates done for you
flowchart LR
subgraph sg0["GitHub Release Input Form Flow"]
direction LR
n0@{ icon: "mdi:swap-vertical", form: "rounded", label: "Config", pos: "b", h: 48 }
n1["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Get Latest Git Tag"]
n2["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Get Commit Date of Latest Tag"]
n3["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Fetch All Merged PRs Since L.."]
n4["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Adjusted: Group PRs & Genera.."]
n5["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Github Pre Release"]
n6["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/> Send message to slack"]
n7["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/form.svg' width='40' height='40' /></div><br/>GitHub Release Input Form"]
n0 --> n1
n1 --> n2
n5 --> n6
n7 --> n0
n2 --> n3
n3 --> n4
n4 --> n5
end
%% Styling
classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
classDef disabled stroke-dasharray: 5 5,opacity: 0.5
class n7 trigger
class n1,n2,n3,n5,n6 api
class n4 code
classDef customIcon fill:none,stroke:none
class n1,n2,n3,n4,n5,n6,n7 customIcon
Why This Matters: Release Notes Always Become a Fire Drill
Most teams don’t “write release notes.” They reconstruct them. Someone opens GitHub, filters PRs, checks what merged since the last version tag, skims titles, clicks into threads for context, then tries to group changes into something that looks intentional. You can lose an hour just figuring out which PRs belong in the release, and another hour rewriting raw PR titles into something humans can scan. Then Slack comes last, so the update is rushed, inconsistent, or skipped. Next release, you repeat the whole mess.
The friction compounds. Here’s where it breaks down for most repos.
- Finding “everything since the last tag” is slower than it should be, especially when multiple people merged work across the week.
- PR titles aren’t written like release notes, so the same change gets described three different ways depending on who merged it.
- If labels aren’t used consistently, grouping changes turns into opinionated guessing and back-and-forth in comments.
- Slack announcements slip through the cracks, so stakeholders learn about changes after the fact (or not at all).
What You’ll Build: Draft Release Notes + a Slack Update from Merged PRs
This workflow gives you a repeatable release routine. You manually trigger it from a simple form, entering the GitHub owner, repository, and target branch. n8n then grabs the newest Git tag, finds the exact commit time for that tag, and uses it as the “starting line” for your next release notes. From there it queries GitHub for all pull requests merged after that timestamp, then organizes them into grouped sections (based on PR labels you define). Finally, it creates a draft GitHub release using the latest tag and the generated markdown, and posts a formatted summary into your Slack channel so the whole team sees what’s shipping.
The workflow starts with a quick form submission in n8n. GitHub is used as the source of truth for tags and merged PRs, and the “assemble” step turns PR data into readable notes. At the end, you get a draft release waiting in GitHub plus a Slack message that’s ready for humans.
What You’re Building
| What Gets Automated | What You’ll Achieve |
|---|---|
|
|
Expected Results
Say you ship weekly and your repo merges about 25 PRs between tags. Manually, it’s common to spend maybe 3 minutes per PR to find it, read it, and translate it into release-note language, plus another 20 minutes to format the final post. That’s roughly 1.5 to 2 hours per release. With this workflow, you spend about 2 minutes filling the form, then a few minutes reviewing the draft release and the Slack message before sending. The busywork mostly disappears.
Before You Start
- n8n instance (try n8n Cloud free)
- Self-hosting option if you prefer (Hostinger works well)
- GitHub for tags, PR history, and draft releases
- Slack to post the release summary to a channel
- GitHub token (PAT) or OAuth (create it in GitHub Developer settings)
Skill level: Beginner. You’ll mostly be connecting accounts, setting label rules, and testing on one repository.
Want someone to build this for you? Talk to an automation expert (free 15-minute consultation).
Step by Step
You submit the release details in a form. In n8n, you enter the repo owner, repository name, and the target branch (like main). That manual trigger is intentional because releases are still a decision, not a background task.
The workflow finds your “starting point.” It fetches the newest Git tag, then pulls the commit timestamp for that tag. That timestamp becomes the cutoff so you only include work merged after the last release.
GitHub PRs are collected and turned into readable notes. n8n queries for merged pull requests after the cutoff time, then a code step groups PRs based on label rules you control. This is where messy PR titles get transformed into a structured markdown draft.
The outputs land in GitHub and Slack. A draft GitHub release is created (so you can edit before publishing), and a formatted summary is sent to Slack so your team sees the highlights immediately.
You can easily modify the label grouping and the Slack formatting based on your needs. See the full implementation guide below for customization options.
Step-by-Step Implementation Guide
Step 1: Configure the Form Trigger
Start by setting up the form trigger that captures the repository details used throughout the workflow.
- Add the Release Info Intake Form node as your trigger.
- Set Form Title to
GitHub Release Input Form. - Configure three required fields: Repository Name, Repository Owner, and Branch Name with the provided placeholders.
Step 2: Connect GitHub
Configure the GitHub API requests that fetch tags and create the draft release.
- Open Fetch Newest Git Tag and set URL to
=https://api.github.com/repos/{{$json["repoOwner"]}}/{{$json["repoName"]}}/tags. - Credential Required: Connect your githubApi credentials in Fetch Newest Git Tag.
- Credential Required: Connect your httpHeaderAuth credentials in Fetch Newest Git Tag if your GitHub setup requires header-based auth.
- Open Create Draft GitHub Release and set URL to
=https://api.github.com/repos/{{ $('Setup Parameters').first().json.repoOwner }}/{{ $('Setup Parameters').first().json.repoName }}/releases. - Set Method to POST and enable Send Body.
- In Body Parameters, set: tag_name to
={{ $('Fetch Newest Git Tag').first().json.name }}, name to={{ $('Fetch Newest Git Tag').first().json.name }}, body to={{ $json.release_notes }}, draft to={{ true }}, and prerelease to={{ false }}. - Credential Required: Connect your httpHeaderAuth credentials in Create Draft GitHub Release.
Step 3: Set Up Data Preparation and Release Notes Processing
These nodes shape the input data, fetch PRs since the latest tag, and assemble the release notes body.
- In Setup Parameters, set repoOwner to
={{ $json['Repository Owner'] }}, repoName to={{ $json['Repository Name'] }}, and defaultBranch to={{ $json['Branch Name'] }}. - In Setup Parameters, set =labelMap to
{ "Feature": "🚀 Features", "bug": "🐞 Bug Fixes", "performance": "⚡ Performance", "sdk": "📦 SDK / Dependency" }. - In Setup Parameters, set =qaChecklist to
[ "[ ] App boots successfully", "[ ] No crash on startup", "[ ] All features tested", "[ ] No broken UI on devices" ]. - Open Retrieve Tag Commit Time and set URL to
={{$json["commit"]["url"]}}. - Open Collect Merged PRs After Tag and set URL to
=https://api.github.com/search/issues?q=is:pr+is:merged+repo:{{ $('Setup Parameters').first().json.repoOwner }}/{{ $('Setup Parameters').first().json.repoName }}+base:{{ $('Setup Parameters').first().json.defaultBranch }}+merged:>={{ $json.commit.author.date }}. - Keep the Assemble Release Notes code unchanged unless you need different grouping or QA checklist formatting.
Step 4: Configure Output Notifications
After the draft release is created, the workflow posts a Slack update with the notes and release URL.
- Confirm the sequence: Assemble Release Notes → Create Draft GitHub Release → Post Slack Update.
- Open Post Slack Update and set URL to your Slack incoming webhook endpoint.
- Set Method to POST and ensure Send Body is enabled.
- Set the text body parameter to
={{ $('Assemble Release Notes').item.json.release_notes }} {{ $json.html_url }}.
Step 5: Test and Activate Your Workflow
Validate the end-to-end flow and then enable it for ongoing use.
- Click Execute Workflow and submit the form in Release Info Intake Form with a real repository, owner, and branch.
- Verify that Fetch Newest Git Tag returns the latest tag and Collect Merged PRs After Tag returns PRs after that commit time.
- Confirm Create Draft GitHub Release generates a draft release with the assembled notes.
- Check Slack for the message posted by Post Slack Update containing the release notes and the release URL.
- When everything looks correct, toggle the workflow to Active for production use.
Troubleshooting Tips
- GitHub credentials can expire or lack permissions. If the PR search or draft release fails, check the token scopes first (you typically need repo access, and draft release creation needs write permissions).
- If GitHub returns “no PRs found,” it’s often the cutoff time or branch name. Confirm your latest tag exists, points to the right commit, and that PRs were merged after that tag’s timestamp.
- Slack messages can come through empty if the release notes field isn’t being passed forward. In n8n, inspect the incoming JSON to the Slack node and make sure the generated markdown or summary text is mapped correctly.
Quick Answers
About 30 minutes if your GitHub token and Slack access are ready.
No. You’ll connect GitHub and Slack, then adjust a few settings like label grouping and message format.
Yes. n8n has a free self-hosted option and a free trial on n8n Cloud. Cloud plans start at $20/month for higher volume. You’ll also need to factor in GitHub and Slack costs (usually $0 for API access in normal use).
Two options: n8n Cloud (managed, easiest setup) or self-hosting on a VPS. For self-hosting, Hostinger VPS is affordable and handles n8n well. Self-hosting gives you unlimited executions but requires basic server management.
Yes, and you should. Most teams start by editing the label map in the “Setup Parameters” node, then tweaking the markdown output in “Assemble Release Notes,” and finally changing the Slack payload in “Post Slack Update” to match their channel style.
Usually it’s token scope or an expired credential. Regenerate your GitHub PAT, ensure it has repo access, then update the credential used by the HTTP Request/GitHub steps in n8n. If you’re running this in an org, SSO enforcement can block tokens until they’re authorized. Rate limiting can also show up if you run it repeatedly across multiple repos in a short window.
Plenty for normal release cycles. Most teams run it weekly or per sprint, and it comfortably handles dozens of merged PRs in a single run; if you’re pulling hundreds, expect longer processing and consider running it off-hours.
Often, yes, because the “since last tag” logic and grouping rules get complicated fast. n8n is happy with multi-step HTTP calls, data transforms, and custom grouping in one workflow, and you can self-host for unlimited executions. Zapier and Make can still work, but you may end up stitching together multiple scenarios, and GitHub search edge cases can get annoying. If you need a lightweight “just notify Slack” setup, those tools are fine. If you’re not sure, Talk to an automation expert and we’ll map it to your release process.
Once this is running, releases stop being a “hope we didn’t miss anything” moment. The workflow does the collecting and formatting, and you get to focus on shipping (and communicating it clearly).
Need Help Setting This Up?
Our automation experts can build and customize this workflow for your specific needs. Free 15-minute consultation—no commitment required.