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 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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? covers what belongs in an entry, and How to write release notes people actually read covers the writing.

Check your own

The 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 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.