Software Release Checklist

A release checklist template for small software teams: scope freeze, testing, docs, support readiness, launch and follow-up. Start each run from CI on a tag.

Typical schedule per release
The checklist 6 sections, 24 items
Variables {{product}} {{version}} {{release_date}}
Start from CI

Use this template Free, no credit card. Imports the checklist into your Runbook organization.

Auf Deutsch lesen: Release-Checkliste für Software

Use this checklist for a versioned release that users will notice: a new version of your web app, a desktop build, a plugin or a customer-facing API change. A release is more than a deployment. It includes the scope decision, testing, documentation, support readiness and the announcement. Start the run when the release branch is cut or the scope is frozen, not on release day, because half of the work happens in the days before.

Who owns it

One release manager owns the run from scope freeze to follow-up. In a small team this is often the tech lead or a rotating engineer. They do not write the docs or the announcement themselves, but they assign those items in the run and chase them. The go or no-go decision is theirs, and it should be recorded in the run.

Common pitfalls

Scope creep after the freeze. "One more small fix" is how releases slip. Late changes go into the next version unless the release manager explicitly accepts them.
Support hears about it from customers. Brief support before the release, with screenshots and the known issues, so they are not learning the new UI live on a call.
Docs that describe the old version. Update help articles and API references in the same release, and link them from the release notes.
No owner for the follow-up. The day after a release is when bug reports arrive. Name who watches them and decides on a hotfix.

Runbook can start this run from your pipeline when the release branch is created, so the checklist and its deadlines exist before anyone has to remember them.

The checklist: Software release: {{product}} {{version}}

Scope and planning

Scope for {{version}} is frozen and the list of included tickets is linked
Anything not merged by the freeze moves to the next version unless the release manager accepts it.
Release date {{release_date}} is confirmed with engineering, support and marketing
Breaking changes and required customer actions are identified
Examples: removed settings, changed API responses, new permissions users must grant.
Release branch or tag candidate for {{version}} is created from the agreed commit

Quality

CI is green on the release candidate, including integration and end-to-end tests
Regression test of the critical user flows is done and signed off
All release-blocking bugs are fixed or explicitly deferred with a reason
Security-relevant changes and dependency updates are reviewed optional
Performance check on the main pages or endpoints shows no obvious regression optional

Documentation and support

Release notes for {{version}} are written in user language, not commit messages
Help articles, API docs and screenshots are updated for changed features
Support team is briefed on new features, breaking changes and known issues
Upgrade or migration guide is published for breaking changes optional

Go or no-go

Go or no-go decision is made and recorded with the names of the people who made it
Base it on agreed criteria: no open blockers, QA sign-off, docs ready, support briefed.
Rollback plan and the previous version number are written down
Someone who knows the release is available for the rest of the day

Launch

{{version}} is deployed or published to all target environments and stores
Smoke test of the released version passes in production
Release notes and changelog are published
Customers are notified by in-app message, email or blog post optional

Follow-up

Error tracking and support inbox are watched for the first day after release
Hotfix decision is made for any serious regression within the first days
Release retrospective is held and follow-up tickets are created optional
Release is marked as done in the issue tracker and the next version is opened

Checklist as Markdown

# Software release: {{product}} {{version}}

## Scope and planning
- [ ] Scope for {{version}} is frozen and the list of included tickets is linked
  Anything not merged by the freeze moves to the next version unless the release manager accepts it.
- [ ] Release date {{release_date}} is confirmed with engineering, support and marketing
- [ ] Breaking changes and required customer actions are identified
  Examples: removed settings, changed API responses, new permissions users must grant.
- [ ] Release branch or tag candidate for {{version}} is created from the agreed commit

## Quality
- [ ] CI is green on the release candidate, including integration and end-to-end tests
- [ ] Regression test of the critical user flows is done and signed off
- [ ] All release-blocking bugs are fixed or explicitly deferred with a reason
- [ ] Security-relevant changes and dependency updates are reviewed (optional)
- [ ] Performance check on the main pages or endpoints shows no obvious regression (optional)

## Documentation and support
- [ ] Release notes for {{version}} are written in user language, not commit messages
- [ ] Help articles, API docs and screenshots are updated for changed features
- [ ] Support team is briefed on new features, breaking changes and known issues
- [ ] Upgrade or migration guide is published for breaking changes (optional)

## Go or no-go
- [ ] Go or no-go decision is made and recorded with the names of the people who made it
  Base it on agreed criteria: no open blockers, QA sign-off, docs ready, support briefed.
- [ ] Rollback plan and the previous version number are written down
- [ ] Someone who knows the release is available for the rest of the day

## Launch
- [ ] {{version}} is deployed or published to all target environments and stores
- [ ] Smoke test of the released version passes in production
- [ ] Release notes and changelog are published
- [ ] Customers are notified by in-app message, email or blog post (optional)

## Follow-up
- [ ] Error tracking and support inbox are watched for the first day after release
- [ ] Hotfix decision is made for any serious regression within the first days
- [ ] Release retrospective is held and follow-up tickets are created (optional)
- [ ] Release is marked as done in the issue tracker and the next version is opened

Start this checklist from your pipeline

When a release branch is cut, POST /api/v1/runs with template "Software release: {{product}} {{version}}" and the planned release_date.

curl -X POST https://runbook.metastic.ch/api/v1/runs \
  -H "Authorization: Bearer $RUNBOOK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"template": "Software release: {{product}} {{version}}", "variables": {"product": "…", "version": "…", "release_date": "…"}}'

See the API and the GitHub Action

Frequently asked questions

What should a software release checklist include?

It should cover the whole release, not just the deploy. That means scope freeze, testing sign-off, release notes, documentation, support briefing, a recorded go or no-go decision, the launch itself and a follow-up period. The technical deploy steps can live in a separate deployment checklist that the release links to.

Who should own the release checklist?

Name one release manager per release. In small teams this rotates between engineers, which spreads the knowledge and avoids one person becoming the bottleneck. The owner assigns items to others, such as docs or support briefing, and keeps the run moving.

How is release readiness different from a pre-deployment check?

Release readiness asks whether the product, the docs and the people are ready for users to see the change. A pre-deployment check asks whether one specific deploy is technically safe to run. A release usually passes readiness once and may then contain several deployments.

Updated 2026-11-04