Generate release notes from a Jira version, automate them on release, and turn ticket lists into notes customers actually read.

Jira can generate release notes for any version. Open Releases, pick the version, and Jira lists every issue with that fix version. That list is written for your team, though: ticket titles, internal jargon, and chores customers never see.
So use Jira to gather what shipped, then rewrite it before it reaches customers. This guide covers both halves: getting release notes out of Jira, and turning them into notes people actually read.
Jira Cloud builds release notes from a version, so the work starts before release day.
Two limits are worth knowing. Release notes pull in rich text and plain text fields only, so images and videos don't come through. And Jira regenerates the notes from the version's current state every time you open them: saving stores the format, not the content. If Rovo is enabled alongside Confluence, you can also toggle Create with Rovo to have AI draft them.
Source: Atlassian's guide to creating release notes in Jira Cloud
If you release often, let Jira Automation send the list for you. The rule has three parts:
Here's the JQL and a message body you can copy. Replace MYPROJECT with your project key, and test the rule on a sandbox version before you rely on it.
Lookup issues (JQL):
project = MYPROJECT AND fixVersion = "{{version.name}}"
Message body:
Release {{version.name}} is out. It includes:
{{#lookupIssues}}
- {{key}}: {{summary}}
{{/}}This gets the list to your team the moment a version ships. It's still a list of ticket titles, so treat it as an internal release note, not the customer version.
Pattern based on this Atlassian Community answer
Jira is great at knowing what shipped. It isn't built to explain why a customer should care.
| What Jira gives you | What customers need |
|---|---|
| Ticket titles, like "PROJ-1423 Refactor invoice approval service" | An outcome, like "Approve invoices without leaving billing" |
| Every issue in the version, chores and internal fixes included | Only the changes a customer can see or has to act on |
| One list for everyone | Notes shaped for end users, admins, and developers |
| Engineering language | Plain words and the reason the change matters |
| A copy-and-paste export | Delivery by email, in-app, and on a public page, plus a way to see who read it |
Add a Release note custom field to your issue types and fill it in when the work is done, while the context is fresh. Whoever closes the issue writes one reader-facing sentence. Release day becomes editing, not archaeology.
Use a label or component such as customer-facing, admin, or api so you can pull each audience's notes with JQL. Leave internal-only work untagged and it stays out of customer notes.
Before anything goes out, have one person check the draft for accuracy and tone, and confirm that anything customers must do sits at the top. A quick look from support catches the questions customers will ask.
Choosing between writing at the source and cleaning up after the fact? Read how to automate release notes without losing quality
Splitting one release across end users, admins, and developers? Read release notes for different audiences
Here's what a Jira export looks like for a typical version:
Version 4.12.0
PROJ-1423 Refactor invoice approval service
PROJ-1431 Add approver role to permissions model
PROJ-1440 Fix PDF footer overlap on long invoices
PROJ-1444 Bump pdf-renderer to 3.2
PROJ-1452 Add 'Pending my review' filter to invoice listAnd here's the same release rewritten for customers:
Approve invoices without leaving billing
September 15 · Pro and Enterprise plans
Reviewers can now approve, reject, or request changes on any invoice, right in billing.
What you need to do: Admins, assign the Invoice approver role in Settings → Roles.
New
- Approve, reject, or request changes on any invoice
- A "Pending my review" filter on the invoice list
Fixed
- Long invoices no longer overlap the PDF footer
Learn more: Setup guide · Contact supportLook at what changed. The headline is an outcome, the refactor and the library bump are gone, and the one thing admins must do sits at the top.
Want this format for your own releases? Copy it from our release note templates
Yes, in two ways. The Releases page generates notes for any version on demand, and a Jira Automation rule triggered by Version released can send the issue list by email or Slack. Both give you a list of issues, so plan a rewrite before customers see it.
Open your project, select Releases, pick a version, then select Release notes. If you're after Atlassian's own notes on what changed in Jira itself, those are published separately in Atlassian's documentation.
You can, but you probably shouldn't. The raw output uses issue titles and includes internal work. Use it as your source list, rewrite it for your readers, and publish it where customers will actually see it.
Neither is built for customers. Jira is good at tracking what shipped and Confluence at internal documentation, but customers expect a public page, an email, or an in-app update. Keep Jira as the source and publish the customer version somewhere made for readers.
Not exactly. The steps on this page follow Jira Cloud's current Releases page. Data Center has its own release notes report for each version, so check Atlassian's documentation for the version you run.
If your team already plans releases in Jira, LaunchNotes connects to it. Shipped work flows into drafts you can edit, target by audience, and publish to a public page, email, and in-app in one step.
See how it works: LaunchNotes release notes for Jira teams