Launch Runbook

qa-testing

incident-response

When to use

• Launching a new website or major redesign
• Migrating from one platform to another
• Releasing a major product or feature
• Coordinating cross-team launches
• Building a runbook for a recurring deploy

When NOT to use

• Pre-launch testing (use

  qa-testing

  )
• Post-launch incident response (use

  incident-response

  )
• After-launch retrospective (use

  after-action-report

  )

Required inputs

• The launch scope (what's being launched)
• The launch window (date, time, duration)
• The team (roles, on-call rotation)
• The rollback criteria (when to abort)
• The communication plan (who tells whom what, when)

The framework: 4 phases

Phase 1: Pre-launch (T-30 days to T-1 hour)

• Final scope locked
• Cross-team commitments confirmed
• Pre-launch QA scheduled
• Comms plan drafted

• Pre-launch QA complete
• All critical and major issues resolved
• Performance baseline measured
• Rollback procedures documented and tested
• DNS TTL lowered (if DNS change is part of launch)

• Final go/no-go meeting
• Roles confirmed
• Communication channels set up
• Backup of current production state

• Team assembled in shared communication channel
• Tools and access verified
• Final smoke test on staging

Phase 2: Cutover (T-0)

1. Announce start to internal team
2. Enable maintenance mode (if applicable)
3. Run final database migrations (if applicable)
4. Deploy code to production
5. Verify deploy completed without errors
6. Run smoke tests on production
7. DNS cutover (if applicable)
8. Verify DNS propagation
9. Disable maintenance mode
10. Run full smoke tests on production
11. Announce launch to internal team
12. Begin monitoring window

• Owner
• Pre-conditions
• Action
• Verification
• Time estimate
• Rollback procedure

Phase 3: Verification (T+0 to T+24 hours)

• Critical user flows working (checkout, signup, login)
• No spike in error rates
• Performance within expected ranges
• Analytics tracking firing
• Email and notifications working

• No regression in key business metrics
• No accumulating error patterns
• Core Web Vitals stable
• Search Console showing no critical issues (if SEO-relevant)

Phase 4: Stabilization (T+24 hours to T+7 days)

• Track error rates day over day
• Track performance day over day
• Track key business metrics vs baseline
• Address any non-blocking issues identified
• Plan the AAR (after-action report)

Roles and responsibilities

Rollback criteria

• Error rate exceeds X percent of normal
• Critical user flow (defined) is broken
• Database integrity issue
• Security vulnerability discovered post-deploy

• Performance degradation beyond Y percent
• Significant degradation in key business metric
• Customer-facing error patterns

Communication plan

Internal channels

• Primary launch channel: Real-time chat for the launch team only
• Status channel: Broader internal updates
• War room: Optional video call for high-stakes launches

Update cadence during launch

• Every 15 minutes during cutover
• Every hour during verification phase
• Daily during stabilization phase

External communication

• Customer-facing announcement: Pre-drafted, scheduled to publish at confirmed-success milestone
• Status page: Updated proactively if any user impact
• Support team: Briefed in advance on what's launching, common questions, escalation path

Workflow

1. Build the runbook 30 days out. Scope, sequence, roles, rollback criteria, comms plan.
2. Test the rollback procedure. Untested rollback is hope, not procedure.
3. Run a tabletop exercise. Walk through the runbook with the full team. Find gaps.
4. Lower DNS TTL 48 to 72 hours before launch (if DNS change is part of launch).
5. Day-of: Run the runbook step by step. Verify each step before moving to next.
6. Monitor. First hour, first day, first week. Document anything noteworthy.
7. Schedule the AAR within 1 to 2 weeks of launch.

Failure patterns

• Runbook written by one person, not reviewed. Single perspective misses scenarios.
• No tested rollback. Discovering rollback is broken at the moment you need it.
• Vague step descriptions. "Deploy to production" without specifying which tool, which command, which environment.
• No verification step after each action. Errors propagate.
• Communication gaps. Team doesn't know launch is happening, or doesn't know it succeeded.
• Launching at end of day Friday. Or before a holiday. Reduce the time available to respond.
• Skipping pre-launch QA to hit a date. The bugs appear on launch day instead.
• Launch fatigue. Long launches without breaks lead to errors. Plan rest cycles for multi-day launches.
• No on-call for first 24 hours. Someone must be reachable.

Output format

launch-runbook-[project].md

1. Launch metadata (what, when, who)
2. Roles and responsibilities
3. Pre-launch checklist (T-30, T-7, T-1, T-1hr)
4. Cutover sequence (numbered steps, owners, verifications)
5. Rollback procedure
6. Rollback criteria (automatic and discretionary)
7. Communication plan
8. Verification checklist (first hour, first day)
9. Stabilization plan (first week)
10. Contacts (escalation paths, on-call)

Reference files

• references/runbook-template.md

  - Fillable runbook template with example cutover sequences.