Posting your changelog to Discord and Slack (without writing a bot)

For a lot of products, the changelog page is the archive but chat is where the update actually lands. Your team lives in Slack; your community lives in Discord; an update posted there gets seen today, in the place where people were already going to talk about it. This guide covers how to wire a #changelog channel up (you almost never need a bot) and the etiquette that keeps people from muting it.

Chat is a pointer, not an archive

Start with the physics of the channel. Chat is push: it reaches people without being asked, at the moment it's posted. It is also ephemeral: the message scrolls away, search is mediocre, history may be truncated on free plans, and someone who joins next month sees nothing. That combination decides the pattern:

  • The canonical entry lives on your changelog — a dated page with a permanent URL, the one-URL rule.
  • The chat post is a mirror: title, a line or two of what the reader can now do, link to the permalink. Discussion happens in chat; the record lives at the URL.

Teams that skip the first half and treat Slack as the changelog hit the wall described in the internal changelogs guide: chat is a notification, not an archive. Six months later, "when did we change the retry behavior?" has no answer a search box can find.

Two platforms, two audiences

Slack is where your team and your customers-in-shared-channels live. A #shipped or #changelog channel keeps support, sales, and adjacent teams honestly informed (the five internal audiences), and a shared customer channel makes the same post do customer-success work.

Discord is where communities live — developer tools, indie games, open source projects. Two Discord-specific features matter. A channel can be marked an Announcement channel, which lets other servers follow it: your patch note posts propagate into your community's own servers. And read-only permissioning is normal there — a #changelog channel where only the webhook can post, with a #general or thread for reactions, is a standard, expected setup. For games this is close to mandatory: patch-day communities expect notes in Discord the minute the patch is live.

Webhooks, not bots

The reflex is "we need a changelog bot." You almost certainly don't. Both platforms have incoming webhooks: a URL that turns any HTTP POST into a message in one specific channel. No OAuth app, no hosting, no library, no permissions review — anything that can make a POST request can post the update, including a CI job or your changelog tool.

  • Discord: channel settings → Integrations → Webhooks → New Webhook → copy the URL. A POST with JSON body {"content": "..."} appears as a message.
  • Slack: create an app (or use a workspace's Incoming Webhooks integration), enable incoming webhooks, add one to the channel, copy the URL. The body is {"text": "..."}.

A bot earns its complexity only when you need interactivity — slash commands, buttons, responding to questions. Posting updates is one-way; a webhook is the whole job.

Treat the webhook URL as a credential. Anyone who has it can post as your integration into that channel. Keep it out of git, keep it in CI secrets, and if it leaks, delete the webhook and make a new one — both platforms make rotation painless.

Wiring it up: three levels of effort

  • Zero code — RSS bridge. If your changelog has an RSS feed, Slack's built-in /feed subscribe [url] subscribes a channel to it, and Discord has well-established RSS-forwarding bots. Updates flow with no infrastructure of yours. The cost: generic formatting and polling delay (minutes to hours).
  • One line of CI. A curl POST to the webhook URL at the end of your release job. Total control of the text; the message ships exactly when the release does.
  • Post-on-publish from your changelog tool. The cleanest loop: publishing the canonical entry is the trigger, so the mirror can never be forgotten, and scheduled posts notify when they go live, not when you wrote them. This is how Wakelog does it (below).

What a good chat post looks like

📣 Scheduled publishing is live

Write the announcement early, set a time, and the post
publishes itself — notifications included.

→ https://yourapp.com/changelog/scheduled-publishing

The rules, compressed: title first (most people read only that line in the notification), one or two sentences of what the reader can now do (their words, not your internal names), the permalink. Don't paste the full entry — a wall of text in chat trains people to scroll past, and the details already have a home. Screenshots earn their place in chat more than anywhere else; one image of the feature beats a paragraph.

Etiquette: staying unmuted

A #changelog channel lives or dies by whether people mute it. The mute button is the chat equivalent of the email unsubscribe — silent, permanent, and unearned pings are how you get there.

  • No @everyone for routine ships. Reserve it for breaking changes and genuinely major launches — the things where "I didn't see it" has a real cost. If everything pings, nothing does.
  • Make the channel read-only; push discussion to threads. Updates drowning in conversation is the failure mode of a shared channel. Read-only keeps the channel scannable as a timeline; threads keep the reactions attached to the right update.
  • One channel, not five. #shipped, #releases, #product-updates and #eng-announcements with overlapping content means nobody knows which to trust.
  • Per-release, not per-commit. A webhook firing on every merge is a commit feed, not a changelog — the curation rule applies to chat more than anywhere, because chat interrupts. If you ship many times a day, mirror a daily or weekly digest instead (cadence guide).

Anti-patterns

  • Chat as the only changelog. Scroll-away history, weak search, and invisible-to-new-members. The channel should point at the record, not be it.
  • The full-text wall. Fifteen paragraphs pasted into Discord reads as noise; the same content behind a one-line summary and a link reads as signal.
  • Webhook URL in the repo. It's a write credential. CI secret, not committed config.
  • Announce-once for breaking changes. Chat posts vanish under new messages within hours. For deprecations, chat is one pointer of several — the announce-three-times rule still stands, and email may still be mandatory.

Where Wakelog fits

Wakelog is a free hosted changelog with the post-on-publish loop built in: paste a Discord or Slack incoming-webhook URL into your project settings and every publish — web, API, CLI, or a CI curl — mirrors to your channel automatically, formatted for the platform (content for Discord, text for Slack, structured JSON for anything else). Scheduled posts notify when they actually go live, drafts stay silent, and every message links back to a permanent dated permalink — the canonical URL the channel points at. RSS and JSON feeds are there too if you'd rather bridge.

Set up your changelog free   Next: how to announce a new feature →

Related guides

Last updated 2026-07-27 · All guides