Public Changelog Template
Before the examples, start with this structure. It keeps a public changelog concise while still giving customers enough context to understand what shipped.
# [Customer-facing update title] Published: [Month Day, Year] [One short paragraph: what changed, who it helps, and why it matters.] ## Added - [New capability customers can use.] ## Improved - [Existing workflow that is faster, clearer, or more reliable.] ## Fixed - [Visible customer problem that no longer happens.] ## Security - [Permission, privacy, compliance, or infrastructure change.] ## Rollout notes [Plan access, migration details, known limitations, or timing.] ## Next step [CTA label]: [URL]
Public Changelog Examples You Can Adapt
Feature launch
New: Saved views for feedback triage
Teams can now save filtered feedback views for common workflows like enterprise requests, billing issues, and high-priority bugs.
- Added saved views for any feedback filter combination.
- Improved share links so teammates open the same filtered view.
- Added workspace-level default views for admins.
Rollout: Available now on Pro and Business workspaces.
Open feedback views
Workflow improvement
Faster changelog review before publishing
The changelog editor now highlights missing screenshots, empty release sections, and unpublished related requests before the update goes live.
- Improved the pre-publish checklist with clearer warnings.
- Added suggested sections for Added, Improved, Fixed, and Security.
- Fixed a preview issue when an update included long code snippets.
Rollout: Rolling out to all workspaces this week.
Review draft changelogs
Bug fix and reliability
CSV exports now keep large feedback lists intact
Large feedback exports are more reliable, especially for workspaces with long histories and multiple active filters.
- Fixed missing rows when exporting filtered feedback lists.
- Improved progress states for exports with more than 10,000 rows.
- Added clearer retry copy when an export cannot finish.
Rollout: Live for every workspace. No action required.
Export feedback
Security and permissions
More precise roles for public changelog publishing
Workspace owners can now decide who can draft, review, and publish public changelog entries.
- Added separate permissions for draft, review, and publish actions.
- Improved audit log entries for changelog edits.
- Fixed an edge case where archived teammates appeared in reviewer menus.
Rollout: Owners can configure the new roles in workspace settings.
Update permissions
Deprecation notice
Legacy changelog import is being retired
The old CSV changelog importer will be removed after teams have time to move imports to the new structured importer.
- Deprecated the legacy CSV import screen.
- Added migration guidance in the new importer.
- Improved validation for dates, authors, labels, and release sections.
Rollout: The legacy importer will be removed on July 1, 2026.
Open the new importer
What These SaaS Changelog Examples Have in Common
Lead with the visible customer outcome
A public changelog should explain the thing a customer can do now, not the internal project name or pull request title.
Use: Saved feedback views are now shareable. Avoid: Added FR-284 saved-filter persistence.
Group updates into scannable sections
Clear SaaS changelog examples usually separate Added, Improved, Fixed, Security, Deprecated, and Removed notes.
Use sections when one release contains multiple kinds of changes.
Say who gets the update
Plan, role, rollout, and migration details prevent support tickets after the changelog is published.
Available now on Business workspaces. Owners can enable it in settings.
End with one useful action
A changelog entry should point readers to the exact product screen, documentation page, or next step.
Open saved views, update permissions, or review the migration guide.
Before You Publish
The headline includes the customer-facing change.
The entry uses plain product language instead of ticket names.
The release date, audience, and rollout status are clear.
Added, Improved, Fixed, Security, and Deprecated sections are separated when needed.
The final CTA sends readers to one useful next step.
FAQ
What are good public changelog examples?
Good public changelog examples include feature launches, workflow improvements, bug fix summaries, security updates, deprecation notices, and release roundups that explain the customer outcome in plain language.
What should a public changelog include?
A public changelog should include a clear title, date, short summary, grouped change bullets, rollout or plan details, known limitations when relevant, and one next step for customers.
How are SaaS changelog examples different from release notes?
SaaS changelog examples are usually shorter, structured records of what changed. Release notes add more context, customer benefits, screenshots, upgrade guidance, and launch narrative.
Can I create a public changelog from raw notes?
Yes. Glink's free Changelog Generator turns commits, pull requests, bug fixes, and product notes into a public changelog draft with customer-ready sections.