Changelog Examples: 12 SaaS Changelogs Worth Copying

Looking at good changelog examples is the fastest way to design your own. This post walks through 12 public SaaS changelogs, the specific pattern each one gets right, and the decisions you need to make before you publish your first entry. At the end there is a changelog entry template you can paste into whatever tool you use.

A public changelog is a running, dated list of what changed in your product. Done well, it shows customers and prospects that the product is alive, gives support and sales a link to share, and becomes a searchable record of every feature you have shipped.

What makes a good changelog?

The best changelogs look different from each other, but they share a few traits:

• Dated, newest first. Readers should see at a glance when something shipped and whether the product is actively developed.
• Written for users. Each entry explains what someone can now do, not which service was refactored.
• Scannable. A clear title per entry, short paragraphs, and consistent labels like New, Improved and Fixed.
• Visual where it helps. A screenshot, GIF or short video for features people need to see to understand.
• Linked. Each entry points to docs or the feature itself, so curious readers can go deeper or try it.
• Subscribable. RSS, email or a social account, so people can follow updates without remembering to visit.
• Permanent. Each entry has its own link, which makes it easy to share in support replies and sales emails.

If you already write release notes, your changelog is where they live in public. Our release notes template covers how to write each individual note.

12 SaaS changelog examples

Every example below links to the live page. Descriptions reflect each page at the time of writing; layouts change, so focus on the pattern rather than the pixels.

1. Linear: one story per entry

Linear's changelog leads each dated entry with one headline feature, explained in a few paragraphs with visuals, followed by grouped lists of smaller improvements and fixes by product area. The changelog sits alongside separate streams for product launches and team posts. Pattern: a strong headline feature on top, the long tail of small changes documented underneath.

2. Vercel: short, filterable posts

Vercel's changelog shows each change as a dated card with a title, a one or two sentence summary and the names of the people who worked on it, with search and category filters. Pattern: many small, focused entries instead of one big monthly round-up, which suits products that ship continuously.

3. Stripe: built around API versions

Stripe's changelog is organised by named API version, separates breaking changes from additive ones, and lets you filter by product area or availability. Signed-in users can narrow it to changes relevant to the APIs they use. Pattern: for developer products, make breaking changes impossible to miss and let readers filter to what affects them.

4. GitHub: labels for every type of change

The GitHub Changelog labels every entry as a release, an improvement or a retirement, adds topic tags, and offers RSS and a dedicated social account. Pattern: a 'Retired' label that makes removals and deprecations as visible as new features.

5. Supabase: tagged entries with a copy-as-Markdown option

Supabase's changelog lists dated entries with a type tag such as 'New Feature', detailed technical write-ups with code where relevant, an RSS feed and an option to copy the page as Markdown. Pattern: making the changelog easy to consume by machines and AI tools as well as people.

6. PostHog: grouped by month, owned by teams

PostHog's changelog groups entries by month, and each entry shows the date, the team that shipped it, the product area and a 'Read the docs' link. It is also available as RSS and Markdown. Pattern: showing which team owns each change, which works well for multi-product companies.

7. Raycast: versioned notes per platform

Raycast's changelog has tabs for each platform, then gives every version a date, a short intro to the main change, and sections for new features, improvements and fixes, each bullet prefixed with the feature it touches. Pattern: a classic versioned format that still feels friendly because of the narrative intro.

8. Resend: the minimal list

Resend's changelog is a clean list: date, title, one-sentence summary and author, with search and a subscribe button. Each title links to a fuller post. Pattern: the easiest format to maintain, because each entry only needs a title and one sentence to go live.

9. Sentry: product features and SDK releases together

Sentry's changelog mixes product announcements with SDK release entries, each with a title, a one-line summary, a date and a link to read more. Pattern: one destination for everything a developer customer might need to know, from new features to library versions.

10. Intercom: problem first, then the fix

Intercom's changes page tags each entry by type and product area, credits the teammate who shared it, and usually opens with the customer problem before describing what changed and linking to more detail. Pattern: problem-then-solution writing, which explains why a change matters to people who did not request it.

11. Cursor: long-form launches inside the changelog

Cursor's changelog gives big releases full write-ups with sub-headings, so a major launch can be explained in depth without leaving the changelog. Pattern: the changelog doubles as the launch post for significant features.

12. Figma: one changelog for many products

Figma's release notes tag each dated entry with the products it affects, use short bullet lists, and give every entry a copy-link button. Pattern: product tags that keep a single changelog usable when a company ships several products.

Changelog patterns: which format should you use?

Across these examples, most public changelogs fall into one of four formats. Pick the one that matches how you ship and how much time you can give it.

Whatever format you choose, be consistent. A changelog that switches style every entry is harder to scan than one that is simply plain.

Changelog entry template

This template covers a single entry in the headline-plus-details format, which suits most SaaS products. For a minimal list, use only the first two lines.

[Date]  [Label: New / Improved / Fixed / Deprecated]

[Title: what users can now do]
[One sentence summary that works on its own in a list view.]

[Short paragraph: the problem this solves and who it is for.]
[Short paragraph: how it works, where to find it, which plans get it.]

[Screenshot, GIF or short video of the feature]

Also shipped
- Improved: [area] - [what is better]
- Fixed: [symptom users saw] when [situation]

[Link: Read the docs] [Link: Try it now]

Write the one-sentence summary first. If you cannot explain the change in a sentence, the entry is not ready, and that sentence will be reused in your email, in-app announcement and social posts anyway.

How to set up a public changelog

1. Choose where it lives. A /changelog page on your own domain keeps the links and search traffic with you. A dedicated changelog tool or a docs platform works too; the point is one permanent URL.
2. Decide your labels. New, Improved, Fixed and Deprecated cover almost everything. Add product-area tags only if you have several products.
3. Set a rhythm you can keep. Shipping entries as features land is ideal; a weekly or monthly round-up is fine. An abandoned changelog with a last entry from long ago looks worse than none.
4. Make collecting changes part of shipping. Ask for a one-line user-facing note on every pull request or ticket that changes the product.
5. Add a way to follow it. RSS is cheap to offer. An email digest or social post for bigger entries reaches people who will never visit the page.
6. Link to it everywhere. Footer, help centre, in-app 'What's new' menu, and support macros.

Changelog mistakes to avoid

• Dumping git history. Commit messages are not changelog entries.
• Only posting big launches. Small fixes show momentum and prove reported bugs get handled.
• No dates. Without dates, readers cannot tell if the product is still being worked on.
• Hiding removals. If you remove or change something people rely on, say so clearly and early.
• Walls of text. Long entries need headings, short paragraphs and one good visual.

Add video to your changelog entries

Several of the changelogs above use images or clips for their headline features, because some changes only make sense when you see them move. A short video at the top of an entry also gives you something to post on social channels, where a link to a text page rarely gets much attention.

You do not need a video for every fix. Save it for the one feature per release that you want people to try, and keep it short. Screenshots of the new feature plus the one-sentence summary from your entry are enough raw material for feature announcement videos that match the rest of your launch.