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.

| Role | Responsibility |
|---|---|
| Launch lead | Owns the runbook. Calls go/no-go. Calls rollback. |
| Deploy operator | Executes the technical deploy steps. |
| QA lead | Runs verification tests and confirms each milestone. |
| Comms lead | Posts internal updates, manages external messaging. |
| On-call engineer | Available for issues during and after launch. |
| Stakeholder rep | Approves on behalf of business stakeholders. |

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.

---

## 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 gap