GitHub release notes templates for features, fixes, and breaking changes

GitHub pull requests are a useful source for release notes, but their titles are rarely ready to publish. These templates help you translate merged work into a customer update without making the announcement vague or overly technical.

Use the template that matches the kind of change, then replace the brackets with facts from the PR description, product spec, and release review.

Feature release template

Use this when customers can do something new.

## [Feature name]: [the outcome it enables]

You can now [customer action] in [product area]. This helps [audience] [practical
benefit].

To get started: [one useful next step, setting, or link].

Example from a merged PR

## Saved customer views: return to the right list faster

You can now save the filters and columns you use most often in the customer
list. This helps account teams return to priority segments without rebuilding
the same view each time.

To get started, set up a filtered customer list and choose Save view.

Improvement template

Use this when an existing workflow became faster, clearer, or more reliable.

## [Workflow] is now [clearer/faster/more reliable]

We improved [product area] so that [customer-visible result]. [Optional detail
that helps readers recognize the change].

## Larger customer exports are more reliable

We improved CSV exports so larger customer lists complete more reliably. You can
keep working while the export is prepared instead of waiting on the list page.

Bug fix template

Use this for a fix customers are likely to have noticed. Keep the focus on the restored behavior rather than the internal cause.

## Fixed: [customer-facing behavior]

We fixed an issue where [plain-language symptom]. [What works correctly now].

## Fixed: duplicate notifications for account owners

We fixed an issue that could send account owners the same notification more than
once. Notifications now arrive once per relevant account event.

Breaking-change template

Use this only when customers need to take action. State the deadline, the affected group, and the safe next step near the top.

## Action required: [what is changing] on [date]

Starting [date], [old behavior] will be replaced by [new behavior]. This affects
[audience]. To prepare, [specific action and link to documentation].

Do not hide a breaking change in a long list of small improvements. If the change could interrupt a workflow, give it its own section and reuse the same wording in the email or in-app announcement.

A compact release template

For a weekly release with several related changes, use this structure:

# [Month] product updates

## New
- **[Capability]** — [customer outcome].

## Improved
- **[Workflow]** — [what is now easier, faster, or more reliable].

## Fixed
- **[Customer-facing issue]** — [restored behavior].

Check the draft against the PR

Before publishing, make sure every sentence can be traced back to shipped work. This small mapping keeps release notes honest without forcing customers to read implementation details.

For a complete workflow, read how to generate release notes from GitHub pull requests. For more formats beyond GitHub, see five release notes templates.

Turn merged pull requests into an editable release-note draft.