Launch Runbook

Launch Runbook

Plan and execute the launch of a website, product, or major release. The runbook is the document everyone uses on launch day. Stack-agnostic.

This skill is for the launch event. For pre-launch QA, use qa-testing. For post-launch incident handling, use 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

A launch has four phases. The runbook covers all four.

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

Verify everything is ready before the launch window.

T-30 days:

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

T-7 days:

• 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)

T-1 day:

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

T-1 hour:

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

Phase 2: Cutover (T-0)

The actual launch. Sequenced steps with owners and verifications.

Standard cutover steps:

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

Each step has:

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

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

Confirm the launch is healthy.

Within first hour:

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

Within first 24 hours:

• 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)

Monitor the long tail.

• 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

A launch has clear role assignments. Ambiguity here is the most common cause of launch chaos.

For small teams, one person may fill multiple roles. Each role's responsibilities should still be explicit.

---

Rollback criteria

Define before the launch. Decisions are easier to make pre-emptively than under pressure.

Automatic rollback triggers:

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

Discretionary rollback triggers:

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

Decision authority: The launch lead calls rollback. Pre-define who acts as deputy if launch lead is unavailable.

---