Blog · 6 October 2026

Automated release notes for Jira: what to automate

Automated release notes for Jira come in two halves, and only one of them automates well. Collecting the list of what shipped is a query, so a Jira Automation rule can run it for you the moment a version is released and post the result to Slack or email. Turning that list into notes a customer wants to read is writing, and it needs an owner, a reviewer and a deadline. The teams that keep their release notes current automate the first half and put the second on a ticket that is created before every release, so nobody has to remember to start it. This guide shows what Jira can do on its own, where the automation stops, and how to keep the human half coming back on schedule.

Statements about Jira are as of October 2026, from Atlassian's own documentation. Atlassian now calls an issue a work item and a project a space. This guide uses the older words where most teams still do.

What "automated" can honestly mean #

Release notes have four jobs, and each has a different answer.

Everything below is about the first, second and fourth rows. The third row is why the last section exists.

Step zero: give every shipped issue a Fix version #

Every automated approach depends on one field. Atlassian's documentation says that when you enable releases, a Fix versions field is added to your work types and a Releases tab appears in the space navigation. Its page on versions also shows how to find the work in a version: switch to JQL and use the FixVersion operator, for example FixVersion = 1.1.

If issues reach "Done" without a fix version, no automation can tell what belonged to the release. The most useful habit is cheap: set the field when work is picked up, not when it ships.

Atlassian's documentation also lists release notes among the kinds of related work you can attach to a version, alongside analytics dashboards, designs and support documentation. That is a place to link the finished notes from, which matters later.

Option 1: a rule that runs when the version is released #

Atlassian's trigger reference lists a Version released trigger, one of three version triggers (created, updated, released), and says versions can be limited with a regular expression. It also says you can use the Version released trigger together with the related work items branch Work item fixed in version to loop through every work item fixed in that version.

That gives you the whole collection step without writing a query:

1. Trigger: Version released.
2. Branch: Work item fixed in version.
3. Action inside the branch: whatever should happen once per issue.
4. After the branch, a single action that reports the result.

If you prefer one summary instead of one message per issue, the Lookup work items action searches up to 100 work items with a JQL query and exposes them as a list you can print in a later action. A JQL on the Fix version field, for example fixVersion = "1.1" AND resolution = Done with the version name filled in, collects the shipped work. Print the keys and summaries as a bulleted list in a Send Slack message or Send customized email action, and the draft lands in a channel the moment you release.

Two limits from the same documentation shape what you can build:

• The Confluence action fills in a title only. Atlassian says the Create Confluence page action creates the page but does not enter any content, so a rule cannot write the body of a release notes page. You can create the page, then paste.
• Lookup tops out at 100 work items. A release larger than that needs the per-issue branch instead, or a second look at how you version.

Option 2: a scheduled rule for a fixed release rhythm #

If you ship every second Thursday regardless of what is ready, the calendar is a better trigger than a version event. Atlassian's reference says a Scheduled trigger runs at a fixed rate, for example every 7 days, or on a cron expression, and can take a JQL query so that the actions run on the work items it finds. Our Jira cron expression guide covers what cron can and cannot say.

One behaviour is worth knowing before you rely on it: the same page says scheduled flows that reach a Failure status for 10 consecutive executions are disabled automatically. A release notes rule that quietly stopped after a bad week is the failure to plan for, so look at the rule's audit log every few releases. Jira Cloud automation limits lists what else a rule is held to.

Option 3: a release notes app from the Marketplace #

Dedicated release notes apps exist on the Atlassian Marketplace, and some of them render the collected list into formatted output for you. If customer-facing notes are a core deliverable, compare a couple of them against the free route above, using the price on their own listing as of the day you look. This guide does not rank them, because the right one depends on where your notes are published.

The half no rule writes: the notes themselves #

A list of 40 issue summaries is not release notes. Issue titles are written for the team ("Refactor token refresh"), and customers want the effect ("You stay signed in on mobile"). Somebody has to:

• group the changes (new, improved, fixed)
• rewrite titles for the reader
• cut what customers should not see
• have the result reviewed
• publish it and link it from the version

This is ordinary recurring work, and it fails in the ordinary way: the release happens, everyone is busy, and the notes are written three days later from memory. The fix is to treat the writing as a ticket with its own deadline, created for you ahead of each release.

Create the release notes ticket before every release #

Here is how a team on a fixed rhythm sets this up with Recurring Work Items for Jira, a Forge app that creates issues on a schedule in the one project where you turn it on. It does not create or release Jira versions and it does not collect the shipped issues. It makes sure the writing task exists.

1. Open Recurring work items in the project menu and create a rule with a task type of your choice.
2. Set the summary with tokens: Release notes for {{now.plusDays(3).monthName}} {{now.plusDays(3).day}}. Tokens are resolved when the run happens, so every ticket carries its own name.
3. Pick the schedule. Every week on a chosen weekday suits a weekly release, Every N set to 2 gives a fortnightly train, and Every month, on a weekday covers "the last Thursday".
4. Run it a few days before the release. The Next runs panel lists the next five dates, so you can confirm they land where you expect before anything is created.
5. Add the steps under Subtasks, each with its own assignee: pull the Fix version list, draft the notes, review, publish and link from the version. A rule creates at most 10 subtasks per run.
6. Put the checking query in the description, for example the JQL for the version, so whoever picks up the ticket starts from the right list.
7. Set the due date to the day before the release, for instance 3 days after, which counts from each run.
8. Under If the previous issue is still open, choose Create nothing until the previous issue is closed if you would rather see one stalled ticket than a pile.

If a release is cancelled, pause the rule. Resuming works out the next run from the moment you press it, so it does not owe you a backlog of tickets. For the wider release routine around this ticket, see the Jira release checklist guide.

When the manual way is enough #

Do not build any of this if:

• You release a few times a year. One person can run the JQL and write the notes in the time it takes to configure a rule.
• Your releases are event-driven and irregular. The Version released trigger fits them better than any calendar, and a recurring ticket would arrive on the wrong days.
• Customers never read the notes. Notes for an internal audience can be the raw list, and the Slack message from Option 1 is already finished work.
• A tool you already pay for writes them. If your delivery platform generates notes from merged work, keep it and use Jira only for the version record.

Frequently asked questions #

Does Jira Cloud write release notes by itself? Atlassian's documentation describes release notes as related work that you attach to a version. The collecting can be automated with a rule on Version released, but the prose is yours.

Can an Automation rule create the Confluence page with the notes in it? Atlassian says the Create Confluence page action sets a title and does not enter any content, so the body still has to be written or pasted.

Which trigger should I use? Version released when your releases happen on events, Scheduled when they happen on a calendar. Many teams use the first for the list and a recurring ticket for the writing.

For more on rules of this shape, see Jira automation examples and Jira recurring tasks.