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. 12 Aug 2026

    Events table is about 6× faster

    Improved

    Cursor pagination instead of offset, and the aggregate is computed in the query. Tables past 50k rows now paint in under 400ms.

  2. 4 Aug 2026

    Scheduled reports

    New

    Send any saved dashboard to a list of addresses on a daily or weekly schedule. Timezone-aware, so a 9am report is 9am for the reader.

  3. 28 Jul 2026

    Fixed funnel steps double-counting returning users

    Fixed

    A returning visitor could be counted twice in one session window. Historical funnels have been recomputed.

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.