Skip to content
Back to Launch & Discoverability

Launch Day Execution

The hour-by-hour playbook for launch day — who does what, when to monitor, what triggers rollback, and how to communicate status.

Why

Launch day compresses months of work into a few high-stakes hours, and without a written playbook the team reacts instead of executes. A runbook assigns every action an owner and a clock time: deploy at 09:00, smoke test at 09:05, announce at 09:30, monitor spike at 10:00. This eliminates the 'I thought you were watching Sentry' failure where nobody owns a critical task. It also pre-decides the rollback trigger — a specific error rate or signup drop — so the decision is made when you are calm, not when you are panicking at 11:00. Teams with a runbook launch in 30 minutes and spend the rest of the day learning; teams without one spend the day firefighting and never get to the announcement.

When

On the target launch date, after the pre-launch checklist is fully green. Start the runbook at T-0 (deploy time) and run it through T+4h (post-launch stabilization).

How

1. T-30min: final go/no-go meeting — confirm checklist is green, rollback owner is on-call, comms owner is ready, status page is green
2. T-0: deploy to production (wrangler pages deploy), record SHA in the runbook channel
3. T+2min: run automated smoke test (Playwright/Cypress) against production; if any critical journey fails, execute rollback immediately
4. T+5min: watch Sentry error rate and Cloudflare dashboard for 10 minutes; trigger rollback if error rate > 1% or 5xx > 0.5%
5. T+15min: post the launch announcement (blog + social + email + Product Hunt if applicable); comms owner confirms each channel is live
6. T+30min: monitor signup rate, server load, and support inbox; the on-call engineer watches dashboards, the support lead watches inbox
7. T+1h: first status check-in meeting (15 min) — review metrics, decide if any hotfix is needed, update status page if any degradation
8. T+2h: second check-in — by now the launch spike is visible; if signup > target and error < threshold, declare launch successful
9. T+4h: stand down the war room; on-call rotates to normal schedule; write a launch-day retrospective within 24h

Example

# Launch Day Runbook — ez4code v2.0
Date: 2026-10-05  War room: #launch-warroom

## Roles
Deploy: @dev-lead  Smoke: @qa  Monitor: @sre
Comms: @marketing  Support: @support-lead  Rollback owner: @cto

## Timeline
09:00 T-30  Go/no-go: all green ✓
09:30 T-0   Deploy SHA a1b2c3d → production
09:32 T+2   Smoke test: 12/12 journeys pass ✓
09:35 T+5   Sentry 0.02%, 5xx 0% — within threshold ✓
09:45 T+15  Announce: blog live, Twitter posted, email sent, PH submitted
10:00 T+30  Signups: 47 (target 30), load 0.3 CPU, 0 support tickets
10:30 T+1h  Check-in: on track, no hotfix needed
11:30 T+2h  Signups: 189, error 0.03% → LAUNCH SUCCESSFUL
13:30 T+4h  Stand down; retrospective scheduled 2026-10-06

## Rollback trigger
Error rate > 1% for 5 min  OR  signup < 50% of target for 15 min
Rollback cmd: wrangler pages deploy dist_astro --branch=prev
Decision: @cto (reachable: Slack + phone)

Common Problems

  • ⚠No designated rollback owner — when metrics go red, three people argue about whether to roll back while users keep hitting the bug; pre-assign one person with the authority and the command.
  • ⚠Announcing before smoke test passes — the marketing tweet goes out at 09:00 but the deploy broke signup at 09:01; sequence must be deploy → verify → announce, never announce → deploy.
  • ⚠Watching only the deploy dashboard, not the support inbox — users report bugs in support 10 minutes before they show up in Sentry; the support lead is your fastest error detector.
  • ⚠No war room — the team is scattered across Slack DMs and nobody has the full picture; a single channel (or physical room) with all roles is the only way to coordinate a launch.

Best Practices

  • ✓Write the runbook as a clock-time document, not a task list — '09:30 deploy' is unambiguous, 'deploy when ready' is not; clock times force decisions and expose slippage immediately.
  • ✓Pre-stage the announcement content (blog draft, social posts, email) in a scheduling tool so the comms owner clicks one button at T+15, rather than composing under pressure.
  • ✓Define the rollback trigger as a numeric threshold, not a feeling — 'error rate > 1% for 5 minutes' is decidable by anyone watching the dashboard; 'if it looks bad' is not.
  • ✓Run a launch-day dry rehearsal 2 days before — deploy to a staging URL, walk through the entire runbook, and time each step; the dry run reveals that the smoke test takes 8 minutes, not 2.