What this template is for
A release is the riskiest hour in software delivery and the easiest one to get wrong by skipping a checklist item. Most release incidents are not caused by bad code - they are caused by skipped QA, missed comms, or a rollback plan that nobody verified.
This template turns the go/no-go meeting into a tracked artefact. Every release has the same sub-task checklist, the same explicit sign-offs, and the same recorded decision.
When to use it
Use this template for:
- Every customer-facing release (web, mobile, API)
- Major version releases of any platform component
- Regulated or compliance-sensitive releases that need an audit trail
Continuous deploys through a CI/CD pipeline do not need a checklist per deploy - those are covered by the pipeline’s own gates. Use this template for the named releases your customers notice.
Sub-task breakdown
STM Issue Templates lays down the eight standard sub-tasks on every release ticket. The post-release 24h monitoring sub-task is the one that catches the slow-burn issues - the bug that only shows up at peak traffic, the regression that only matters on the next day’s batch run. Auto-creating it means the release does not feel ‘done’ until the monitoring window has closed.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | Release v4.13.0 - go/no-go checklist | Yes |
Release Version (custom) | v4.13.0 | Yes |
Release Date | 2026-05-30 | Yes |
Release Manager (custom) | @release-manager | Yes |
Scope Summary (custom) | 12 features, 38 fixes; linked release ticket PROJ-1400 | Yes |
QA Sign-off (custom) | Approved by @qa-lead 2026-05-29 | Yes |
Security Sign-off (custom) | Approved by @security-eng 2026-05-29 | Yes |
Release Notes URL (custom) | https://example.com/changelog/v4.13.0 | Yes |
Rollback Plan (custom) | Re-deploy v4.12.4 image; feature flags off | Yes |
Comms Plan (custom) | Status page banner; in-app notice for breaking change | No |
Linked Deploy Ticket | PROJ-1620 | No |
Go / No-Go (custom) | Go (decided 2026-05-29 17:00 UTC) | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Confirm all in-scope tickets are merged or explicitly descoped
- QA sign-off: regression pass complete, blocker count = 0
- Security sign-off: no open critical findings
- Release notes drafted and reviewed by product
- Rollback plan confirmed and tested in staging
- Customer comms drafted (status page, in-app, email if breaking)
- Go/no-go meeting and decision logged on the ticket
- Post-release: monitor for 24h and confirm metrics within bounds
Common questions
What is a release checklist in Jira used for?
It is the per-release go/no-go gate - a single ticket where QA, security, release notes, rollback plan, and customer comms all have to be signed off before the release ships. The ticket is the artefact of the decision; the sub-tasks are the checklist; the Go/No-Go field is the recorded outcome. It is also the post-mortem starting point if the release goes wrong.
How do you decide go or no-go on a release?
The release manager runs the go/no-go meeting, walks the checklist, and asks each owner (QA, security, product, ops) for an explicit yes or no. Any 'no' is a no-go unless mitigated and re-decided. The decision and the reasoning go on the ticket so anyone joining post-release can see why a known issue was accepted or descoped.
Should every release have its own checklist ticket?
Every release that ships to customers, yes. Internal-only or canary deploys may use a lighter template, but anything that customers will see should have a tracked go/no-go decision. The ticket becomes part of the release's permanent record alongside the release notes and the deploy ticket.
How do you avoid release-checklist drift?
Use [STM Issue Templates](/stm/) to lay down the standard sub-task set on every release ticket - it is the cheapest way to keep the checklist consistent across release managers and across quarters. The checklist evolves with each post-release review; STM ensures the latest version is what gets applied to the next release.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →