Blog · 4 October 2026

Jira release checklist: the steps, where they live, and the cadence

A Jira release checklist works best split in two. Jira's own release page already checks the parts a machine can see: whether the work items in a version are done, whether their code is merged and their builds pass. The rest is human work that no integration knows about, such as release notes, a support briefing, a rollback plan and a go or no-go call. Put that second half in a release ticket with one subtask per step, and if your team ships on a fixed rhythm, have that ticket created for you before each release instead of copying it by hand. This guide gives you a checklist to start from, shows what Jira covers out of the box, and explains how to keep the list coming back every cycle.

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.

A Jira release checklist you can copy #

Most release checklists fall into four phases. Trim this to what your team actually does, because a checklist with steps nobody performs teaches everyone to tick boxes without reading them.

Two of those rows point at Jira itself: checking warnings and marking the version released. The next section covers what Jira does there, so your checklist does not duplicate it.

What Jira's release page already checks #

If your space has the releases feature turned on, each version gets a release page. Atlassian's documentation describes using it to verify that:

• work items are complete
• code is checked in, reviewed, and merged
• builds are passing
• work items have been deployed to the correct environment
• any related work is complete
• any warnings are addressed

The warnings depend on which development tools you have connected. Atlassian lists three kinds:

• Open pull requests: a work item is marked done but still has an open pull request.
• Unreviewed code: a work item is marked done, but its commits are not part of a pull request or code review.
• Failing builds: a work item is marked done but is linked to a failing build.

A few other details from the same documentation are worth knowing before you plan around the page:

• The release date of an unreleased version turns red once its planned release date has passed.
• You need space admin permissions to release a version.
• When you release, Jira asks what to do with any unresolved work items and asks for a release date.
• Releasing a version changes where it appears in drop-downs for fields such as Fix version.

So the release page is your checklist for code state. It cannot know whether support was briefed, whether release notes exist, or whether anyone wrote down how to roll back. Those steps need a home of their own.

Where the human steps should live #

There are three common places, and each suits a different team.

Subtasks are the shape most teams settle on, because a step with an assignee and a status is a step somebody can be chased about. QA sees the regression step on their own board. The product owner sees the release notes step in their own queue. When every subtask is done, the parent can close, and the history of each release stays findable. Our Jira subtask template guide covers four ways to get the same subtasks every time, and the Jira checklist template guide compares in-ticket checklists with subtasks in more depth.

Whichever you pick, the weak spot is the same one: the list only exists when somebody starts it. A release checklist that depends on a person remembering to create it fails on exactly the release where that person is busiest.

Releases on a calendar, and releases on demand #

How you solve that depends on what decides a release.

If releases happen when the work is ready, the trigger is an event. Jira Automation can react to it. Atlassian's trigger reference, as of October 2026, says the version trigger "listens for versions being created and released, as well as being amended", and that the flow "will run when a version is created, updated or released". A rule on Version created can create a release ticket with its subtasks the moment someone creates the next version. That is a good fit for teams that release irregularly. Our Jira Automation examples guide walks through rules of that shape, and Jira Cloud automation limits covers what each run spends.

If releases happen on a fixed rhythm, the trigger is the calendar. A weekly Thursday release, a release train every second week, or a monthly release on the first Tuesday all share one trait: you know the date months in advance, and the checklist should be waiting before the release week starts. You can do this with a scheduled Automation rule and a cron expression (our Jira cron expression guide covers the syntax and the schedules cron cannot express), or with a scheduling app.

Create the release checklist before every scheduled release #

Here is how a fixed-cadence team 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.

1. Open Recurring work items in the project menu and create a rule. Pick a task type for the release ticket.
2. Set the summary with tokens so every release ticket has its own name, for example Release checklist {{now.monthName}} {{now.day}}, {{now.year}}.
3. Choose the schedule. Every week on a chosen weekday covers a weekly release. Set Every N to 2 with a start date on a release week for a fortnightly train. Every month, on a weekday covers "the first Tuesday" or "the last Thursday".
4. Set the time a few days ahead of the release itself, so the ticket appears with time to work through the freeze steps.
5. Add the steps under Subtasks, each with its own summary, description and assignee. A rule creates up to 10 subtasks per run, so group the twelve rows above into ten or fewer, for example by folding the three "After" steps into one.
6. Set the due date. 1 week after or 3 days after counts from each run, so the deadline moves with every cycle.
7. If the release must never land on a weekend or holiday, choose Move it to the previous working day under If it falls on a non-working day. The due date moves with it.
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 release than a stack of overlapping checklists.

Before saving, the Next runs panel lists the next five dates, so you can confirm the rule lands on release weeks before it creates anything. If a release is cancelled, pause the rule. Resuming works out the next run from the moment you resume, so it does not create a backlog of checklists for the weeks it was paused.

One thing this app does not do: it does not create or release Jira versions. Keep using the release page for that. The rule's job is to make sure the human half of the checklist exists, with owners and a deadline, every time.

When the manual way is enough #

A scheduled checklist is overhead you do not need in every case. Do it by hand, or with a template you apply on demand, when:

• Releases are rare or irregular. Two releases a year do not justify a rule, and an event-driven Automation rule fits irregular releases better than any calendar.
• One person does every step. A short list in the ticket description is faster to read than five subtasks assigned to the same name.
• The steps change every time. A checklist that needs rewriting per release is a planning conversation, and copying last release's ticket is the honest starting point.
• Your deploy pipeline enforces the checks. If merges are blocked on failing builds and unreviewed code, the release page warnings mostly confirm what the pipeline already guarantees, and your checklist can shrink to the human steps.

Frequently asked questions #

Does Jira have a built-in release checklist? Not as a list you edit. The release page shows progress and warnings for a version's work items, which covers code state. Steps such as release notes, support briefings and rollback plans need a ticket, subtasks or a checklist of your own.

Who can release a version in Jira? Atlassian's documentation says you need space admin permissions to release a version.

Can Jira create a release ticket automatically? Yes. Jira Automation can create one when a version is created or released. For releases on a fixed date, a scheduled Automation rule or a scheduling app such as Recurring Work Items for Jira creates the ticket and its subtasks on the calendar.

Should the checklist be subtasks or a checklist field? Subtasks when different people own different steps, because each step then has an assignee and a status. An in-ticket checklist when one person works through the whole list.

For the wider picture of recurring work around a sprint, see Jira for sprint planning and Jira recurring tasks.