Changelog for SaaS: The Complete Guide to a Changelog People Read

A SaaS changelog is a public, versioned record of what changed in your product and why it matters to the reader — not a git log, not a support document, and not a marketing feed. This guide covers the format, placement, and maintenance practices that separate the changelogs customers actually read from the ones that die after three releases.

What a SaaS changelog is (and is not)

The useful definition: one entry per release, written for the person using the product, published somewhere they can find it. Three corollaries follow:

• It is user-facing by default. Internal refactors, dependency bumps, and infra work belong in the release commit message, not the changelog — unless they change something the user can feel.
• It is versioned and dated. Entries are ordered newest first, each tied to a version or a date, so "what was different in March" is answerable.
• It is cumulative, not a press release. A changelog is a log: it keeps old entries. News and announcements get their own channel.

A common failure mode is the hybrid: half changelog, half blog, with "we are excited to announce" entries that will not be useful in six months. Keep the announcement energy out.

Entry format that holds up

The Keep a Changelog format is the default for a reason: each release entry has a version, a date, and sections such as Added, Changed, Deprecated, Removed, and Fixed. For a SaaS audience, adapt it:

• Lead with the big thing. The one or two changes users care about go first, in plain language.
• Then the list. Smaller changes follow as bullets, grouped (Added / Changed / Fixed).
• Flag breaking changes explicitly. A Breaking marker at the top of the entry beats discovery by failure.
• Link, do not paste. Each bullet can link to docs or help articles for people who want depth.

An entry that reads well:

v2.4 — 2026-08-20
Breaking: API key rotation now invalidates old keys immediately instead of after 24 hours.
- Added: CSV export for all report types.
- Added: Keyboard shortcuts for the dashboard.
- Fixed: Timezone handling in scheduled exports.

Placement and discovery

A changelog nobody finds is no changelog. The working standard for SaaS products:

1. In-product. A "What's new" link in the main nav or sidebar — this is where your existing users actually are.
2. A public URL. A stable, guessable page (for example /changelog) that you can put in emails, docs, and your README.
3. An RSS feed. For people who live in feed readers, and for integrations.
4. An email digest. The most-read channel for many products; a per-release or monthly digest beats hoping people visit the page.

The in-product link plus an email digest is the minimum that makes the changelog a real product surface.

Tone: write for the reader, not the repo

The gap between a git log and a changelog is the same gap between "refactored auth middleware" and "sign-in is faster and no longer drops your session." Three rules:

• Outcomes over tasks. "Exports no longer fail on files over 100 MB" is a changelog line; "fixed bug in export worker" is not.
• No internal names. Users do not know what svc-billing is, and they do not need to.
• Consistent register. One voice across entries: past tense for what happened, present for what it means.

Teams with multiple audiences — developers, customers, stakeholders — often need more than one register per release; the release notes for multiple audiences guide covers that split in depth.

Keeping it current on every release

The changelog that gets read is the one that updates itself. Manual writing is where most changelogs die: the friction compounds and the page goes stale, which our article on why changelogs get outdated dissects. The fix is structural: tie entry generation to the release event (a tag, a deploy, a merged PR) so the entry exists the moment the release does, and keep a human review step that edits the draft before it publishes.

ShipChangelog

ShipChangelog is a hosted implementation of this guide: merged PRs become draft entries in a clean Added/Changed/Fixed shape, breaking changes are flagged, and each release is published in three audience versions with a public page, RSS, and email digest. Free for one repo with 5 entries a month; Pro at $12.99/month adds three repos, unlimited entries, a custom domain, and private changelogs.

FAQ

How long should a SaaS changelog entry be?

The lead takes two sentences; the rest is a short bulleted list. If an entry needs a paragraph of context, that context belongs in a docs page that the bullet links to — the changelog line stays one line.

Should we list every bug fix?

User-visible fixes, yes; internal ones, no. A good test: would a customer care that this specific bug is fixed? If the answer is "only if the bug bit them," one line is enough, or leave it out.

Changelog or release notes — do we need both?

They overlap heavily for SaaS. Pick one surface — the changelog — and let it carry the release-notes content. Separate documents drift apart; one page with per-release entries does not.

ShipChangelog writes these changelogs for you — start free with 1 repo.