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#
| Criterion | Met? | 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 | |
| Outcome | Success / Rolled back / Partial |
| Issues encountered | |
| Follow-up actions |