Skip to content

Changelog

Publish once. It shows up everywhere it should.

The reason changelogs die isn’t writing them. It’s that publishing one is only step one, and then you still have to tell people. Here, publishing is telling people.
  1. 21 Aug 2026

    Slack integration for alerts

    slackintegration

    Connect slack to usefull notifications

  2. 21 Aug 2026

    Updated and fixed the plugin using plugin-check

    feedfastwordpress

    Now FeedFast plugin is complete clean

  3. 21 Aug 2026

    Team members and roles

    New

    Invite teammates and give them read-only or admin access. Still being written.

  4. 15 Aug 2026

    Scheduled maintenance windows

    New

    You can now announce planned downtime ahead of time. - Pick a window and the monitors it affects - Subscribers get an email when it's sched…

Scroll the timeline. These are live entries from the demo changelog.

One publish, four surfaces

Where an entry lands the moment you hit publish

  1. Your public page

    A single column with generous vertical rhythm: date eyebrow, title, tag badges, rendered markdown. Each entry also gets its own URL, so a support reply can point at exactly the release that fixed something.
  2. A real RSS feed

    Not a marketing checkbox, an actual feed at /p/your-slug/rss.xml that readers, aggregators and automations can subscribe to without you building anything.
  3. The widget on your own site

    A floating “What’s new” badge with an unread dot, or entries rendered inline as cards or a list. Users find out inside the product they’re already using, which is the only place they reliably look.
  4. Your status subscribers' inbox, if you want

    The same verified list that gets incident and maintenance notices, no second list to build, no second unsubscribe to honour.

Writing

A two-pane editor and nothing to learn

Markdown on the left, the exact public styling on the right. What you see while writing is what ships.
  • Tags as coloured badges. New, Improved and Fixed out of the box, or your own.
  • Drafts are real drafts. Nothing is public until you publish; the entry keeps its slug either way.
  • Syntax-highlighted code blocks. Fence a block with a language and it’s highlighted server-side, from a library of hundreds of grammars loaded on demand. Useful when your release notes are for developers.
  • Markdown is sanitised before it renders. Highlighting runs after sanitising, so no author-supplied markup is ever re-parsed as HTML.

Or don't write it yourself

FeedFast ships an MCP server, so Claude Code, Cursor, Windsurf or any MCP client can publish the entry for the thing it just helped you fix: reading the original request off your board and linking the reply to the release note. It asks you before anything goes public.

Presentation

It looks like your product, not like a tool

A changelog page that obviously belongs to someone else is worse than no changelog page.
  • Your logo, uploaded and served as WebP at the size it's shown
  • Your accent colour, carried through links, buttons and badges
  • Times rendered in each reader's own timezone, from a UTC source
  • Entries separated by whitespace rather than borders: set like a publication
  • On Pro the 'Powered by FeedFast' badge comes off entirely
  • Readable at 375px, with visible focus rings and reduced-motion respected

Write the first entry today

Free for one project, fifteen entries to start, and the widget included. The next thing you ship can tell your users by itself.