Changelog examples

Five patterns for a public changelog, with an example entry for each — and the three habits that separate a changelog people subscribe to from one nobody opens twice.

What a good changelog entry looks like

Before the patterns, the shape. Almost every changelog entry worth reading has the same four parts, in this order:

A date and a name. “14 March — Scheduled exports”. Version numbers are fine as well, but they are not a title.
One sentence of outcome. What a reader can now do that they could not do yesterday.
The detail, underneath. Steps, limits, screenshots — for the people who read on.
An exit. A link to the feature, the docs, or a way to reply.

Pattern 1 — the dated release

One entry per release, newest first. The default for products that ship every week or two, and the easiest to keep up with.

14 March 2026 — Scheduled exports

Set an export to run every Monday morning instead of remembering to click
the button. Settings → Exports → “Schedule”.

Existing manual exports are unchanged.

Pattern 2 — the grouped roundup

Added / Improved / Fixed. Borrowed from the “Keep a Changelog” convention, and the best fit when a release is a dozen small things rather than one big one.

v1.7.3

Added
- Partial-word search: “inv” now finds “invoice”

Improved
- The project list remembers your last sort order
- Faster first load on slow connections

Fixed
- Uploads over 10 MB failed silently on Safari
- The date picker showed the wrong month in UTC+13

Pattern 3 — the story entry

One release, written as a short post: what was wrong, what you did, what it means. It costs more to write, so save it for the changes you want people to talk about.

Search is fast now

Search used to take about two seconds on large accounts, which is long
enough that people stopped using it and scrolled instead.

We moved the index off the main database and rebuilt how results are
ranked. On the largest account we have, search now returns in under
100 ms — and it matches partial words, which was the other half of the
complaint.

Nothing to turn on. If it still feels slow for you, email us your
account name and we will look at it directly.

Pattern 4 — the monthly digest

For teams that ship continuously — or so rarely that one entry per release would leave months of gaps. Instead of publishing forty entries nobody follows, publish one a month that a reader can finish.

What shipped in March

The headline: scheduled exports.

Also this month: partial-word search, a faster first load, and seven bug
fixes including the Safari upload failure several of you reported.

Coming next: shared dashboards. Email us if you would like early access.

Pattern 5 — the non-software update

A changelog is not only for software. A shop, a studio or a community group has the same problem: something changed, and the people who care need to find out without being asked to follow yet another social account.

Summer hours start on 1 July

We open at 7am and close at 3pm on weekdays through August, and we are
closed on Sundays.

Preorders are unaffected — the cut-off is still 6pm the day before.

Three habits that make the difference

Publish on a URL, not only in an in-app popup. A popup is dismissed once and gone. A page can be linked from a support reply, found in search, and read by someone deciding whether to sign up.
Offer a feed. RSS costs you nothing and lets the people who care most follow along without an account or an email address.
Keep the cadence honest. A changelog with a two-year gap says more about the product than an empty one. If you ship rarely, use the monthly digest and skip the months with nothing in them.

Starting your own

The Latest gives you a page for exactly this: dated entries, newest first, with an RSS feed generated automatically and a one-line widget if you want the latest few on your own site. Pick a pattern above, paste the example, and change the words.

Start for free Release notes templates →Changelog vs release notes →See all features