🔓 Unlock all 10,000+ workflows & prompts free Join Newsletter →
✅ Full access unlocked — explore all 10,000 AI workflow and prompt templates Browse Templates →
Home n8n Workflow
January 22, 2026

GitHub + Slack: release notes and updates done for you

Lisa Granqvist Partner Workflow Automation Expert

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

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

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.

  1. Add the Release Info Intake Form node as your trigger.
  2. Set Form Title to GitHub Release Input Form.
  3. Configure three required fields: Repository Name, Repository Owner, and Branch Name with the provided placeholders.

You can open the form directly from the Release Info Intake Form node to validate field labels before testing the workflow.

Step 2: Connect GitHub

Configure the GitHub API requests that fetch tags and create the draft release.

  1. Open Fetch Newest Git Tag and set URL to =https://api.github.com/repos/{{$json["repoOwner"]}}/{{$json["repoName"]}}/tags.
  2. Credential Required: Connect your githubApi credentials in Fetch Newest Git Tag.
  3. Credential Required: Connect your httpHeaderAuth credentials in Fetch Newest Git Tag if your GitHub setup requires header-based auth.
  4. 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.
  5. Set Method to POST and enable Send Body.
  6. 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 }}.
  7. 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.

  1. In Setup Parameters, set repoOwner to ={{ $json['Repository Owner'] }}, repoName to ={{ $json['Repository Name'] }}, and defaultBranch to ={{ $json['Branch Name'] }}.
  2. In Setup Parameters, set =labelMap to { "Feature": "🚀 Features", "bug": "🐞 Bug Fixes", "performance": "⚡ Performance", "sdk": "📦 SDK / Dependency" }.
  3. In Setup Parameters, set =qaChecklist to [ "[ ] App boots successfully", "[ ] No crash on startup", "[ ] All features tested", "[ ] No broken UI on devices" ].
  4. Open Retrieve Tag Commit Time and set URL to ={{$json["commit"]["url"]}}.
  5. 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 }}.
  6. Keep the Assemble Release Notes code unchanged unless you need different grouping or QA checklist formatting.

⚠️ Common Pitfall: The Collect Merged PRs After Tag URL depends on Setup Parameters values; ensure your form inputs match the exact repository owner, name, and branch.

Step 4: Configure Output Notifications

After the draft release is created, the workflow posts a Slack update with the notes and release URL.

  1. Confirm the sequence: Assemble Release NotesCreate Draft GitHub ReleasePost Slack Update.
  2. Open Post Slack Update and set URL to your Slack incoming webhook endpoint.
  3. Set Method to POST and ensure Send Body is enabled.
  4. Set the text body parameter to ={{ $('Assemble Release Notes').item.json.release_notes }} {{ $json.html_url }}.

⚠️ Common Pitfall: The Post Slack Update node has an empty URL by default—add your Slack webhook or the request will fail.

Step 5: Test and Activate Your Workflow

Validate the end-to-end flow and then enable it for ongoing use.

  1. Click Execute Workflow and submit the form in Release Info Intake Form with a real repository, owner, and branch.
  2. Verify that Fetch Newest Git Tag returns the latest tag and Collect Merged PRs After Tag returns PRs after that commit time.
  3. Confirm Create Draft GitHub Release generates a draft release with the assembled notes.
  4. Check Slack for the message posted by Post Slack Update containing the release notes and the release URL.
  5. When everything looks correct, toggle the workflow to Active for production use.
🔒

Unlock Full Step-by-Step Guide

Get the complete implementation guide + downloadable template

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

What’s the setup time for this GitHub Slack release automation?

About 30 minutes if your GitHub token and Slack access are ready.

Is coding required for this release notes automation?

No. You’ll connect GitHub and Slack, then adjust a few settings like label grouping and message format.

Is n8n free to use for this GitHub Slack release workflow?

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).

Where can I host n8n to run this automation?

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.

Can I modify this GitHub Slack release workflow for different use cases?

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.

Why is my GitHub connection failing in this workflow?

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.

What volume can this GitHub Slack release workflow process?

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.

Is this GitHub Slack release automation better than using Zapier or Make?

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.

Lisa Granqvist

Workflow Automation Expert

Expert in workflow automation and no-code tools.

×

Use template

Get instant access to this n8n workflow Json file

💬
Get a free quote today!
Get a free quote today!

Tell us what you need and we'll get back to you within one working day.

Get a free quote today!
Get a free quote today!

Tell us what you need and we'll get back to you within one working day.

Launch login modal Launch register modal