Template · Free

Release Checklist

What must be true before you ship — with a rollback that has been tested rather than assumed, and a go/no-go with a named decision-maker.

No sign-up. No email. Markdown — edit it in anything.

When to use it

Every production release.

Who fills it in

Release manager.

Works alongside: QA Checklist · Security Checklist · Incident Report

The template

Instruction lines are marked with > — delete them once the document is filled in.

Release: _______________ Date / window: _______________ Release manager: _______________ Go/no-go decision-maker: _______________


1. Before the day#

  • [ ] Scope frozen; what is in this release is written down
  • [ ] QA checklist complete and signed
  • [ ] Security checklist complete and signed
  • [ ] Change approved through whatever governance applies
  • [ ] Stakeholders told what is changing and when
  • [ ] Support team briefed on new behaviour and known issues
  • [ ] Documentation and release notes updated
  • [ ] Dependencies confirmed ready (other teams, vendors, data)

2. Rollback — decided before you need it#

  • [ ] Rollback procedure written, step by step
  • [ ] Rollback tested, not assumed
  • [ ] Backup taken immediately before release, and its restore verified
  • [ ] Database changes are reversible, or a forward-fix is prepared
  • [ ] Point of no return identified: after step ___, rollback is no longer possible
  • [ ] Rollback decision-maker named: _______________

The most common cause of a long outage is discovering during the incident that the rollback does not work.

3. Go / no-go#

CriterionMet?Notes
All blocking defects closed
Environments healthy
Team available for the window
No conflicting change in flight
Business timing acceptable

Decision: GO / NO-GO By: _______________ Time: _______________

4. Deployment#

  • [ ] Announce start
  • [ ] Maintenance page enabled, if applicable
  • [ ] Backup confirmed complete
  • [ ] Deploy
  • [ ] Configuration and secrets verified in the target environment
  • [ ] Database migrations run and verified
  • [ ] Caches invalidated where needed
  • [ ] Maintenance page removed

5. Verification — before declaring success#

  • [ ] Smoke test of critical paths passes
  • [ ] Authentication works, including a fresh login
  • [ ] A real transaction completes end to end
  • [ ] Integrations responding
  • [ ] Error rates normal
  • [ ] Response times normal
  • [ ] Logs show nothing unexpected
  • [ ] Scheduled jobs still running
  • [ ] Customer data intact — verified by count or checksum, not by assumption

"The site loads" is not verification. Verify the thing the business depends on.

6. After#

  • [ ] Announce completion
  • [ ] Monitor for an agreed period: ___ hours
  • [ ] Release notes published
  • [ ] Version tagged in source control
  • [ ] Changelog updated
  • [ ] Previous version retained for rollback until: _______________
  • [ ] Retrospective scheduled if anything went wrong

7. If it goes wrong#

Symptoms that trigger rollback:

Who decides: _______________ How long we try to fix forward before rolling back: ___ minutes


Record#

Started
Completed
OutcomeSuccess / Rolled back / Partial
Issues encountered
Follow-up actions