---
title: Changelog examples: 15 public changelogs and what each does well
description: Fifteen public changelogs from real software companies, what each one does well, and what we could verify about them — feeds, entry pages and how often they post — as read on 27 September 2026.
canonical: https://relnotely.com/blog/changelog-examples
published: 2026-09-28
updated: 2026-09-28
---

# Changelog examples worth learning from

Fifteen public changelogs, chosen because each does at least one thing well enough to copy. What we say about feeds, entry pages and rhythm was read from their pages and feeds on 27 September 2026; what we say each does well is our opinion.

The best way to learn what a changelog should look like is to read a few good ones. Here are fifteen, from companies whose changelogs are read by a lot of people, with a note on what each does well.

Two kinds of statement are mixed on this page, and it is worth being clear which is which. The facts — whether a page announces a feed, whether entries have pages of their own, how many entries the feed held and how recently it posted — were read by the [Changelog Grader](/tools/changelog-grader) on **27 September 2026** and are stated as of that date. What each changelog "does well" is our opinion. Pages change; if something here is out of date, tell us and we will fix it.

## Product changelogs

### Linear

[linear.app/changelog](https://linear.app/changelog). Announces its feed, gives every entry a page of its own, and posted 37 times in the year to 27 September 2026 — almost exactly one entry a week, with the newest three days before we read it.

**Does well:** one entry per week, each with a headline change and a tail of smaller improvements under it. Readers learn when to look, and a week's small fixes get read because they travel with something bigger.

### Vercel

[vercel.com/changelog](https://vercel.com/changelog). A feed at a usual path (though the page itself does not announce it), a page for every entry, and a feed 500 entries long with several posts on some days.

**Does well:** one entry per change, however small. Nothing waits for a roundup, so the changelog is also the fastest way to find out whether a thing has shipped.

### Figma

[figma.com/release-notes](https://www.figma.com/release-notes/). Announces its feed, gives every entry a page, and had 122 entries in the year to 27 September 2026 with the newest two days old.

**Does well:** separating release notes from the marketing blog, so the notes can be plain and complete rather than written to impress.

### Notion

[notion.com/releases](https://www.notion.com/releases). Announces a feed, and every one of the 152 entries in it links to a page of its own.

**Does well:** a page per release with the screenshots that a feed reader or an email would lose, and a title that names the feature rather than the version.

### Raycast

[raycast.com/changelog](https://www.raycast.com/changelog). Announces its feed; the ten entries in it are a week apart and each has a page.

**Does well:** versioned releases — this is a desktop app — with the version number and the date both on the entry, so a user can tell whether they have a change.

### Cursor

[cursor.com/changelog](https://cursor.com/changelog). A feed at a usual path, fifty entries in it, each with its own page, posting every four days or so.

**Does well:** entries written for the people who use the product every day, naming the shortcut or the setting a change lives behind.

## Developer product changelogs

### Supabase

[supabase.com/changelog](https://supabase.com/changelog). Announces its feed, gives every entry a page, posted 62 times in the year to 27 September 2026 (every three days, by the median), and offers an email field on the page itself.

**Does well:** treating the changelog as something to subscribe to, with the sign-up on the page rather than behind a marketing form.

### PostHog

[posthog.com/changelog](https://posthog.com/changelog). Announces its feed; 74 entries in the year, every four days or so, each with a page.

**Does well:** volume without noise. Many small entries, each titled with what changed, in a product that ships constantly.

### Resend

[resend.com/changelog](https://resend.com/changelog). Announces its feed; 57 entries in the year, one every five days by the median, each with a page, the newest five days before we read it.

**Does well:** short entries. Most say what changed in two or three sentences and stop, which is the right length for a change most readers only need to know exists.

### GitHub

[github.blog/changelog](https://github.blog/changelog/). Announces its feed and offers an email field on the page. The feed itself was too large for our reader to count, so we make no claim about its rhythm.

**Does well:** labels. Every entry is tagged by product area, so a reader who cares about one part of a very large product can filter to it.

### Stripe

[docs.stripe.com/changelog](https://docs.stripe.com/changelog). An API changelog inside the documentation, organised by API version and date.

**Does well:** putting breaking changes where developers already are, with the version they arrive in. This is the model for any product with an API: the changelog is part of the docs, not the marketing site.

### Cloudflare

[developers.cloudflare.com/changelog](https://developers.cloudflare.com/changelog/). A changelog inside the developer docs, grouped by product, for a company with a great many products.

**Does well:** one page that covers everything, with the product named on every entry, so the answer to "did anything change in the thing I use" is one search away.

## Small company changelogs

### Ghost

[ghost.org/changelog](https://ghost.org/changelog/). Announces its feed, gives every entry a page, offers an email field, and posts roughly every eight days.

**Does well:** entries with a picture and a paragraph, written by people who clearly use the product, from an open-source company that has kept the same changelog going for years.

### Plausible

[plausible.io/changelog](https://plausible.io/changelog). Announces its feed; ten entries in it, each with a page, about nine days apart.

**Does well:** a changelog that is calm. A small team, a modest rhythm, and every entry still dated and linkable — proof that none of this needs a big company.

### Slack

[slack.com/changelog](https://slack.com/changelog). A long-running changelog for a large product, organised by date.

**Does well:** longevity and a stable address. A changelog that has been at the same place for years is one that customers, support teams and search engines all know to look at.

## What the good ones have in common

Reading fifteen of these side by side, the things that make a changelog useful are few and not hard:

- **A date on every entry**, in the entry, not only in the address.
- **A page for every entry**, so a release can be linked from a support reply, a social post or a search result.
- **A feed**, announced in the page's head, so readers and automation can follow it without handing over an address. This is the thing most often missing: of the 23 changelogs we read for this page on 27 September 2026, 12 had a feed we could find and 10 announced it.
- **A rhythm.** Among the 12 with a feed, the median gap between posts was five days, and nine had posted within the previous thirty days. The number matters less than the gaps not growing.
- **Titles that say what changed.** "Export any report to CSV", not "September update".

[What is a changelog?](/blog/what-is-a-changelog) covers what belongs in an entry, and [How to write release notes people actually read](/blog/how-to-write-release-notes) covers the writing.

## Check your own

The [Changelog Grader](/tools/changelog-grader) reads any public changelog and reports the same facts used on this page, with a score out of 100 and what to change. The [Last Shipped Badge](/tools/shipped-badge) reads a changelog's feed and shows, on a README or a website, how long ago the product last shipped.

## About this list

The companies named here own their names, and none of them has endorsed this page or has any connection with Relnotely; they are named to identify the changelogs described. The pages were chosen for being widely read, not ranked, and are in no particular order within each group. Everything stated as fact was read from each company's own public page and feed on 27 September 2026 with the method published on the Changelog Grader's page, and opinions are marked as ours. If we have something wrong, write to us and we will correct it.

## Questions

**What makes a good changelog?**

A date on every entry, a title that says what changed, an address of its own for each entry so it can be linked, a feed so it can be followed, and a steady rhythm. Of the 23 well-known changelogs we read for this page on 27 September 2026, only about half had a feed we could find, which is the most common thing missing.

**How often do good changelogs post?**

Among the 12 changelogs on this page with a feed we could read, the median gap between posts on 27 September 2026 was five days, and nine had posted within the previous thirty. Weekly is a fine rhythm for a small team; what matters is that the gaps do not grow.

**Should every changelog entry have its own page?**

Yes. It is what lets a release be linked from support replies, social posts and search results. Eleven of the twelve changelogs here with a feed gave every entry its own address.

**Can I check my own changelog the same way?**

Yes. The free Changelog Grader on this site reads any public changelog and reports the same facts used for this page — feed, entry pages, dates, rhythm — with a score and the reasons for it.

---

Published by Relnotely at https://relnotely.com/blog/changelog-examples
