Release Notes Template (Free) + 10 Great Release Notes Examples

A good release notes template saves you from staring at a blank page every time you ship. This guide gives you two free templates you can copy today (a short customer-facing one and a fuller versioned one), a step-by-step process for writing release notes, and 10 real release notes examples from SaaS and software teams, with what each one does well.

Release notes are the record of what changed in a specific release and why it matters to the reader. They are not a commit log. The commit log is for engineers; release notes are for the people who use, buy or support your product.

What should release notes include?

Most useful release notes answer the same five questions, in roughly this order:

1. What is this release? A version number, a date, or both, so people can tell which build they are on.
2. What is new? New features and capabilities, described by what the user can now do.
3. What got better? Improvements to existing features: speed, usability, new options.
4. What got fixed? Bugs that customers may have noticed, described by the symptom they saw.
5. What do I need to do? Breaking changes, deprecations, required migrations or settings to turn on.

Optional extras that help: a screenshot or short clip for the headline change, a link to the docs, and who to contact if something breaks. Leave out internal ticket numbers, refactors nobody can see, and anything that only makes sense inside your team.

Release notes template (short, customer-facing)

Use this for a single feature or a small batch of changes. It works in an in-app 'What's new' panel, a changelog page, an email or a Slack community post. Replace everything in square brackets.

[Feature name]: [one-line benefit]
[Date]

You can now [do the new thing] directly from [where in the product].
Before, [the old, slower or missing way]. Now, [the new way in one sentence].

How to try it:
1. Go to [screen or menu].
2. Click [button or setting].
3. [What happens next.]

Also in this update:
- Improved: [improvement, described as a user outcome]
- Fixed: [bug, described by the symptom users saw]

Available on: [all plans / Pro and above / rolling out over the next few days]
Learn more: [link to docs]

Two things make this template work. The headline names the benefit, not just the feature. And the 'How to try it' steps turn a passive announcement into something the reader can act on in under a minute.

Release notes template (full, versioned)

Use this when you ship numbered releases: desktop or mobile apps, APIs, SDKs, self-hosted software, or a monthly roll-up for a web app. It is the format most software release notes examples follow.

[Product name] [version number]
Released [date]

Highlights
[Two or three sentences on the most important change and who it is for.]

New
- [Feature]: [what users can now do]. [Link to docs]
- [Feature]: [what users can now do].

Improved
- [Area]: [what is better and how users will notice].
- [Area]: [what is better and how users will notice].

Fixed
- [Symptom users saw] when [situation]. ([platform, if relevant])
- [Symptom users saw] when [situation].

Breaking changes and deprecations
- [What changed], which affects [who]. To keep things working, [action] before [date].
- [Feature or endpoint] is deprecated and will be removed on [date]. Use [replacement] instead.

Known issues
- [Issue] - workaround: [workaround].

Upgrade
[How to update, or note that web users get it automatically.]

Questions? [Support link or contact]

Delete any section that is empty for a given release. An empty 'Known issues' heading reads like you forgot to fill it in.

How to write release notes, step by step

Templates handle structure. The quality comes from the writing. Here is a process that keeps release notes accurate and readable without turning them into a big project.

1. Collect changes as you ship, not at the end

Ask whoever merges a user-facing change to add a one-line, plain-English note to the pull request or ticket. A label like 'release-note' makes these easy to pull together later. Writing from memory a month later is how fixes get lost and features get described wrongly.

2. Sort by impact on the reader

Put the change most people will care about first, even if it was the smallest engineering effort. Then group the rest into New, Improved and Fixed. If a release has one big feature and twenty small fixes, the feature deserves its own paragraph and the fixes can be a compact list.

3. Write each item as a user outcome

Swap the engineering description for what the user experiences. 'Refactored export queue' becomes 'Large exports now finish without timing out.' 'Fixed null pointer in invite flow' becomes 'Fixed an error some people saw when inviting a teammate by email.'

4. Be specific and honest

Name the screen, the setting and the plan. If something is rolling out gradually, say so; people will otherwise assume it is broken. If you removed something, say what replaces it. Vague notes like 'various improvements and bug fixes' tell readers nothing and erode trust over time.

5. Flag anything that requires action

Breaking changes, deprecations and required migrations should never be buried in a bullet list. Put them in their own section with a clear deadline and the exact action to take. This matters most for API and developer products.

6. Add one visual for the headline change

A screenshot, GIF or short video of the main feature does more than three extra paragraphs. Keep it to the one change that benefits from being seen; not every bug fix needs an image.

7. Publish where people will actually see it

The same note can live in several places: a public changelog page, an in-app announcement, a product update email, your community and social channels. Write it once in the template above, then trim it for each channel rather than writing five versions from scratch.

10 release notes examples worth studying

These are public release notes pages from well-known software companies, each linked so you can see the current version. Descriptions reflect the pages at the time of writing; layouts change, so look at the patterns rather than copying any one page.

1. Slack desktop release notes

Slack's Mac release notes list each version number with its date and a short 'Bug Fixes' or 'What's new' section, with separate pages for each platform. Worth copying: a consistent, light-hearted voice that makes even a minor update readable, and per-platform pages so people only see what applies to them.

2. Visual Studio Code

VS Code's updates page opens each versioned release with a short 'Release highlights' summary and download links, then goes deep on each area. Previous versions are one click away in a sidebar. Worth copying: a skimmable summary above a detailed body, so casual readers and power users are both served.

3. Raycast

Raycast's changelog gives each version a date, a short narrative intro about the headline change, then clear sections for new features, improvements and fixes, each line prefixed with the area it touches. Worth copying: the area prefix on every bullet (for example 'AI Chat:' or 'Clipboard History:') makes long lists easy to scan.

4. Notion

Notion's What's New page pairs a version number and date with a headline that names the main feature, then explains the problem it solves in a few friendly paragraphs. Worth copying: leading with the 'why' before the 'what', which suits big releases aimed at non-technical users.

5. Stripe API changelog

Stripe's changelog is organised by API version, with breaking changes clearly separated and filters by product area. Worth copying: if you have an API, treat breaking changes as their own category and let developers filter to what affects them.

6. Intercom

Intercom's changes page tags each entry by type and product area, then writes it as a short problem-and-solution story followed by a 'Learn more' link. Worth copying: opening each note with the customer problem before describing the fix.

7. Figma

Figma's release notes show dated entries tagged with the products they affect, short bullet lists of what changed, and a copy-link option on each entry. Worth copying: product tags, which help when one company ships several products from one page.

8. GitHub Changelog

The GitHub Changelog labels every item as a release, an improvement or a retirement, and lets you filter by topic or subscribe via RSS. Worth copying: a 'Retired' label, which makes removals as visible as additions.

9. Linear

Linear's changelog leads each dated entry with a headline feature and visuals, then follows with a grouped list of smaller improvements and fixes by area. Worth copying: one story per release, with the long tail of small changes still documented underneath.

10. Cursor

Cursor's changelog publishes dated entries with a clear headline and sub-headings that break a large launch into digestible parts. Worth copying: sub-headings inside a single note, which keep a big release readable without splitting it into several posts.

Software release notes example: before and after

Here is a typical first draft and the same note rewritten with the principles above.

v2.14.0
- Added CSV export
- Perf improvements
- Fixed bug #4821
- Updated dependencies

Version 2.14 - [date]

Export any report to CSV
You can now download any report as a CSV file from the Share menu, so you can work with your data in a spreadsheet without copying it by hand. Available on all plans.

Improved
- Dashboards with many charts now load noticeably faster.

Fixed
- Fixed an issue where some scheduled reports were sent twice.

The 'after' version drops the invisible dependency update, names where the feature lives, says who gets it, and turns a ticket number into a symptom customers will recognise.

Common release notes mistakes

• Copying the commit log. Engineers write commits for each other; customers cannot parse them.
• Burying breaking changes. Anything that needs action belongs at the top or in its own section.
• Writing for the team, not the reader. Internal codenames and project names mean nothing outside the company.
• Over-promising. Do not announce a feature as available to everyone if it is still rolling out.
• Publishing nothing at all. Shipping silently makes the product look stagnant even when the team is busy.

Turn your release note into a feature announcement video

Your release notes are text, but your headline feature often lands better when people can see it. A 20 to 45 second clip showing the new feature in context works well at the top of a changelog entry, in the announcement email, and on social channels where a wall of text gets scrolled past.

The good news is that a well-written release note is already most of a video script: the headline is your opening line, the 'before and now' sentence is the problem and solution, and the 'How to try it' steps are your scenes. Pair it with two or three screenshots of the feature and you have everything you need for one of these feature announcement videos.

If you publish release notes publicly, the next step is a changelog page that collects them. See these changelog examples for layouts worth borrowing.