Launch Checklists

Overview

A launch checklist is a structured gate that prevents releases from going to production before they are ready. Without one, "ready" is a subjective judgement made under time pressure — usually by whoever is most optimistic about the state of the code. With one, "ready" is a verifiable list of conditions. Launch checklists do not slow releases down; they prevent the incidents and rollbacks that do.

For assessing the risk profile of a release before the checklist is applied, see Risk Assessment Frameworks. For managing a phased release after the checklist is passed, see Rollout Strategies.

Why It Matters

Incidents caused by incomplete releases are more expensive than delayed releases. A production incident that requires a rollback, a hotfix, or an outage costs significantly more than the time it would have taken to run through a checklist before launching.

Checklist items represent learned lessons. Every item on a well-developed launch checklist is there because something went wrong without it — either in this team's history or in the broader engineering community. Treating checklist items as bureaucracy misunderstands their origin.

Checklists create shared accountability. When a release passes a checklist, multiple people have verified multiple conditions. No single engineer carries the full accountability for a release's readiness. This distributes the cognitive load and catches the things individuals miss.

A checklist is a communication tool as well as a quality gate. Running through a checklist with the team before a launch surfaces the questions nobody thought to ask, the dependencies nobody confirmed, and the rollback paths nobody tested. The conversation is as valuable as the sign-offs.

Checklists scale. As a team and product grows, it is impossible to rely on individuals to remember everything that must be true before a release. A checklist is institutional knowledge in actionable form.

Standards & Best Practices

The T-minus launch timeline

Organise pre-launch work into a T-minus timeline based on the size and risk of the release:

For minor releases (no user-facing changes, no data migrations), compress or skip stages as appropriate. Never skip the launch-day checklist.

Pre-launch checklist

Group the checklist by category to make ownership clear:

Engineering readiness:

• All planned stories completed and merged to main
• UAT passed (no open Critical or High severity defects)
• Automated tests passing (unit, integration, regression)
• Code reviewed and approved by at least one engineer who did not write it
• Deployment to staging verified successfully
• Performance benchmarks within acceptable range
• Security review complete (for releases that change auth, data handling, or external integrations)

Data and migrations:

• Database migrations tested in staging
• Rollback migration script exists and tested
• Backup taken before migration runs in production
• Data migration dry-run completed (for large or complex migrations)

Observability:

• New monitoring dashboards created and verified
• Alerts configured for new failure modes
• Logging in place for new code paths
• On-call runbook updated (if this release introduces new operational complexity)

Rollout:

• Rollout strategy confirmed (full release / canary / feature flag / phased)
• Rollback plan documented and tested
• Rollback trigger criteria defined
• Feature flags configured correctly (if applicable)

Communications:

• Internal teams notified (support, sales, customer success)
• Customer-facing release notes prepared (if applicable)
• Stakeholders notified of launch date and scope
• On-call coverage confirmed for the launch window

Launch-day checklist

On the day of release:

• Deployment executed following the documented rollout plan
• Post-deployment smoke test passed
• Key metrics confirmed in normal range (error rate, latency, core flows)
• First monitoring window covered (at least 1 hour of active monitoring after launch)
• On-call engineer confirmed available for the first 24 hours

Rollback trigger criteria

Define in advance the specific conditions that trigger an immediate rollback:

• Error rate exceeds [X]% for any 5-minute window
• P95 latency exceeds [Y]ms
• Core flow (checkout / login / main user action) success rate drops below [Z]%
• Any Critical severity defect reported by monitoring or customer support

Rollback trigger criteria should be written into the launch checklist, not decided reactively.

How to Implement

Checklist ownership

Assign one person as checklist owner for each launch. This person:

• Is responsible for ensuring each item is completed, not for completing each item themselves
• Has authority to delay a launch if checklist items are incomplete
• Records sign-offs for each checklist section

The checklist owner is typically the product manager or the engineering lead, depending on the team structure.

Tailoring the checklist by release type

Not every checklist item applies to every release. Maintain a tiered checklist:

Define what constitutes each tier at the start of the project, not when the release is imminent.

Tools & Templates

Launch checklist (full template)

## Launch Checklist — [Release name]

**Release date:** [Date]
**Release type:** Minor / Standard / Major
**Checklist owner:** [Name]
**On-call engineer:** [Name]

### Engineering readiness

- [ ] All stories complete and merged
- [ ] UAT passed (no open Critical/High defects)
- [ ] Automated tests passing
- [ ] Staging deployment verified
- [ ] Security review complete (if applicable)

### Data and migrations

- [ ] Migrations tested in staging
- [ ] Rollback migration exists and tested
- [ ] Pre-migration backup scheduled

### Observability

- [ ] Dashboards updated
- [ ] Alerts configured
- [ ] Runbook updated

### Rollout

- [ ] Rollout strategy confirmed: [strategy]
- [ ] Rollback plan: [brief description]
- [ ] Rollback triggers: error rate > [X]% / latency > [Y]ms / [other]
- [ ] Feature flags configured: [flag names]

### Communications

- [ ] Internal teams notified
- [ ] Release notes prepared
- [ ] On-call coverage confirmed

### Launch-day

- [ ] Deployment complete
- [ ] Smoke test passed
- [ ] Metrics in normal range at T+1hr

**Launch approved by:** [Name] **Date:** [Date]

Common Pitfalls

Treating the checklist as a formality. Checklists that are signed off without actually verifying each item are the most dangerous kind — they provide the appearance of rigour without the substance. Require evidence for each sign-off (a link, a screenshot, a test result) rather than just a checkbox.

No rollback plan. A launch without a tested rollback plan is a launch where all failure paths lead to an incident. Rolling back should be as well-understood and rehearsed as deploying. If you cannot answer "how long would a rollback take?" before launching, you are not ready to launch.

Not defining rollback triggers in advance. "We'll roll back if things go wrong" is not a trigger. Rollback trigger criteria defined reactively — during an incident — are defined too slowly, under too much stress, by people who are too invested in the release succeeding. Define the triggers before launch.

Skipping comms for "small" releases. Support teams receiving customer queries about a feature change they were not notified about is avoidable. "Small" features that change user-visible behaviour are not small from the support team's perspective. Notify customer-facing teams for all user-visible changes.

No post-launch review. Launches that are not reviewed produce no learning. Post-launch reviews close the loop: did the release go as planned? Were there incidents? Were the rollback triggers correctly defined? These learnings improve the next launch.

The checklist that only exists in someone's head. Institutional knowledge that is not written down is lost when the person who carries it leaves or is unavailable. The checklist must be a document, not a mental model.