Examples

Changelog Examples: Five Formats and What Makes Them Work

Brian SierakowskiFounder4 min read
Five changelog page layouts displayed side by side with a figure reviewing them from a clipboard
In short

A good changelog example shows a dated entry written in customer language: what changed, who it affects, and what to do next. Five formats cover most products — the dated feed, the grouped release, the single-feature post, the maintenance roundup, and the API changelog — and the right one depends on how often you ship and who reads.

Changelog advice is easy to find and hard to act on. “Write for the customer” is true and useless at the moment you’re staring at a merge list.

So here are five formats, written out. Pick the one that matches how often you ship and who reads.

1. The dated feed

The default for most products. One reverse-chronological page, one heading per date, a handful of items under each.

## September 18, 2026

**Saved filters** - Any filter combination on the list view can now be saved
and shared with your team. Saved filters appear in the sidebar for everyone
with access to the workspace.

**Faster exports** - CSV exports of more than 10,000 rows now stream instead
of building in memory. Large exports start downloading immediately.

**Fixed** - Comment notifications no longer arrive twice when a thread is
reopened.

What makes it work: every entry leads with the noun the customer recognizes, not the system that changed. “Saved filters,” not “filter persistence service.”

If several products share one feed, tag each entry by product so a reader can filter to the one they use. The lack of that filter is one of the most common reasons teams outgrow their first changelog tool.

2. The grouped release

For teams that ship on a version cadence, especially with a self-hosted or installable product.

## v4.2.0 - September 18, 2026

### Added

- Saved filters on all list views
- Webhook retries with exponential backoff

### Changed

- Exports over 10,000 rows now stream
- The settings page is reorganized into Account, Billing, and Team

### Fixed

- Duplicate comment notifications on reopened threads
- Timezone drift on scheduled reports for UTC+13 and higher

### Deprecated

- `GET /v1/reports/legacy` will be removed on December 1, 2026

What makes it work: the Added / Changed / Fixed / Deprecated headings are a convention readers already know from Keep a Changelog, so they can scan for the section that affects them. The cost is that it reads like a spec, which makes it a poor fit for a non-technical audience.

3. The single-feature post

For launches that deserve their own page, linked from the feed.

## Saved filters

Every team we talked to had one person who rebuilt the same filter every
morning.

**The problem.** List views supported filtering, but nothing persisted. Close
the tab and the filter was gone, which meant the same six clicks at the start
of every session and no way to hand a view to a teammate.

**What is new.** Any filter combination can now be saved, named, and shared
with the workspace. Saved filters appear in the sidebar and can be set as the
default view for a project.

**How to use it.** Apply any filter, then click Save view in the toolbar.

[Read the docs](#) - [Open your list view](#)

What makes it work: the problem paragraph. It gives the reader somewhere to stand before the feature arrives.

4. The maintenance roundup

For cycles where nothing is individually newsworthy but the work still matters.

## Stability and performance - September 2026

This cycle went to reliability. The highlights:

- **Exports** - Large CSV exports stream instead of buffering, so they no
  longer time out over 50,000 rows.
- **Notifications** - Duplicate sends on reopened threads are gone.
- **Scheduled reports** - Timezone handling corrected for UTC+13 and above.

Plus 24 smaller fixes across search, billing, and the mobile web view.

What makes it work: it converts invisible work into evidence that the product is maintained. A customer deciding whether to renew reads this differently than you wrote it — as proof of life.

5. The API changelog

For anything developers integrate against. This is the one that has to be precise.

## 2026-09-18

**Added** - `POST /v1/filters` and `GET /v1/filters` for saved filters.

**Changed** - `GET /v1/exports` now returns `202 Accepted` with a `location`
header for exports over 10,000 rows, instead of blocking until the file is
ready. Smaller exports are unchanged.

**Deprecated** - `GET /v1/reports/legacy` is deprecated and will be removed on
2026-12-01. Use `GET /v1/reports` with `format=legacy`.

What makes it work: exact paths, exact status codes, exact dates. An API changelog is read by someone deciding whether their code breaks, and ambiguity there costs them an afternoon.

What the good ones have in common

Across all five formats, the same four properties show up:

  1. Dated. Every entry carries a date, so a reader can tell what’s recent and an AI assistant can tell what’s current.
  2. Written from the outside in. The entry names what the customer sees, and the implementation only appears if it changes what they should do.
  3. Published somewhere stable and crawlable. A public page on your own domain with a feed, not a Notion doc and not a Slack message. See your deploy message in Slack is not a changelog.
  4. Consistent. A predictable rhythm gets read. Sporadic excellence does not.

The part that actually stops teams

None of these formats are difficult. What stops teams is the translation step — reading a week of commits and pull requests, deciding which changes a customer would notice, and rewriting each one in language that isn’t engineering language — plus the fact that nothing triggers it. The feature ships, attention moves to the next one, and the changelog quietly falls three features behind.

The Changebot Agent does that pass for you — it reads your GitHub or Bitbucket history and drafts entries in whichever of these shapes you use, for a human to edit and approve. Publishing is free: a hosted page, an embeddable widget, your own domain, Slack, RSS, and MCP for the assistants your customers ask.

Frequently Asked Questions

What does a good changelog entry look like?

A dated entry with a title in customer language, one or two sentences describing what changed and why it matters, and a link to documentation or to the feature. It names the customer-visible effect rather than the internal implementation.

What is the difference between a changelog and a release notes page?

A changelog is the running, dated list of everything that changed. Release notes are the narrative written for a specific release. In practice most teams publish release notes as entries in a changelog, and the two words get used interchangeably.

Should a changelog include screenshots?

For anything visual, yes. A screenshot or short clip is the fastest way to make a UI change legible, and it stops readers from having to reconstruct the feature from your prose. Maintenance entries do not need them.

Where should a changelog live?

On a public page on your own domain, with an RSS or Atom feed, and ideally surfaced in-app through a widget. Public and crawlable means customers, search engines, and AI assistants can all find it; in-app means the people already using the product see it.