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.

---

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#

Default output: a markdown runbook at launch-runbook-[project].md plus supporting checklists.

Structure:

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 (opens in a new tab) - Fillable runbook template with example cutover sequences.

---

Supporting file: references/runbook-template.md#

Launch Runbook Template#

Fillable runbook for a launch. Copy this template, fill in specifics for your launch.

---

Launch metadata#

What's launching: [Specific scope. "New marketing site at example.com replacing the legacy site."]

Launch date: [YYYY-MM-DD]

Launch window start: [Time, timezone]

Launch window end: [Time, timezone]

Maintenance window required: [Yes / No, and if yes, expected duration]

Launch lead: [Name + contact]

Deputy launch lead: [Name + contact, in case primary is unavailable]

---

Roles#

---

Pre-launch checklist#

T-30 days#

• Final scope locked and signed off
• Cross-team commitments confirmed
• Pre-launch QA scheduled
• Communications plan drafted
• Rollback procedure documented

T-14 days#

• Pre-launch QA in progress
• Performance baseline measured (current production)
• Critical and major issues triaged
• Internal launch announcement drafted

T-7 days#

• All critical issues resolved
• All major issues resolved or accepted with mitigation
• Rollback procedure tested in staging
• DNS TTL lowered to 60 to 300 seconds (if DNS change is part of launch)
• Final go/no-go date confirmed

T-2 days#

• Final go/no-go meeting held
• Decision: GO / NO-GO / DEFER
• All team members confirmed available for launch window
• Backup of current production state taken
• Customer support briefed on what's launching

T-1 day#

• Final smoke test on staging passes
• Communication channels set up
• On-call rotation confirmed for first 24 hours
• Pre-drafted internal and external messaging ready

T-1 hour#

• Team assembled in launch communication channel
• All required tools and access verified
• Final smoke test on staging passes
• Launch lead confirms GO

---

Cutover sequence#

For each step:

• Owner: Person executing
• Pre-condition: What must be true to start
• Action: What to do
• Verification: How to confirm success
• Estimated time: How long this should take
• Rollback: What to do if this step fails

---

Step 1: Announce start#

• Owner: Comms lead
• Pre-condition: Launch lead has confirmed GO
• Action: Post in internal status channel: "Starting launch of [scope] at [time]. Expected duration: [X minutes]."
• Verification: Message posted, key stakeholders confirmed they saw it
• Time: 2 minutes

Step 2: Enable maintenance mode#

• Owner: Deploy operator
• Pre-condition: Step 1 complete
• Action: [Specific command or action to enable maintenance mode]
• Verification: Visit production URL, confirm maintenance page is showing
• Time: 2 minutes
• Rollback: Disable maintenance mode

Step 3: Final database migrations#

• Owner: Deploy operator
• Pre-condition: Step 2 complete, database backup confirmed
• Action: [Specific migration command]
• Verification: Migration log shows success, schema verified
• Time: [estimate]
• Rollback: Restore from backup taken in T-2

Step 4: Deploy code to production#

• Owner: Deploy operator
• Pre-condition: Step 3 complete
• Action: [Specific deploy command or CI trigger]
• Verification: Deploy log shows success, version endpoint returns new version
• Time: [estimate based on past deploys]
• Rollback: Re-deploy previous version

Step 5: Run smoke tests on production#

• Owner: QA lead
• Pre-condition: Step 4 complete
• Action: Run smoke test suite against production
• Verification: All smoke tests pass
• Time: [estimate]
• Rollback: If failures, evaluate severity. Critical failures = rollback to step 4.

Step 6: DNS cutover (if applicable)#

• Owner: Deploy operator
• Pre-condition: Step 5 passes
• Action: Update DNS records: [specific records and values]
• Verification: Use dig or DNS lookup tools to confirm new records propagating
• Time: Propagation up to 5 minutes (if TTL was lowered) up to 24+ hours (if not)
• Rollback: Revert DNS records to previous values

Step 7: Disable maintenance mode#

• Owner: Deploy operator
• Pre-condition: Step 6 verified
• Action: [Specific command to disable maintenance mode]
• Verification: Visit production URL, confirm new site loads
• Time: 2 minutes

Step 8: Full smoke test on production#

• Owner: QA lead
• Pre-condition: Step 7 complete
• Action: Run full smoke test suite (more comprehensive than step 5)
• Verification: All tests pass; critical user flows verified manually
• Time: [estimate]
• Rollback: If failures, evaluate. Critical failures = full rollback.

Step 9: Announce success#

• Owner: Comms lead
• Pre-condition: Step 8 passes
• Action: Post in internal status channel: "Launch complete. All checks pass."
• Verification: Confirmed by stakeholders
• Time: 2 minutes

Step 10: Begin monitoring window#

• Owner: On-call engineer
• Pre-condition: Step 9 complete
• Action: Begin elevated monitoring for first 60 minutes. Watch error rates, performance, key business metrics.
• Verification: Dashboards open, alerts armed
• Time: Continuous

---

Rollback procedure#

If rollback is called, execute these steps:

1. Announce rollback in internal status channel
2. Re-enable maintenance mode (if applicable)
3. Revert DNS records to previous values (if changed)
4. Re-deploy previous code version
5. Restore database from backup (if migrations were destructive)
6. Verify previous version is functioning
7. Disable maintenance mode
8. Run smoke tests on rolled-back state
9. Announce rollback complete
10. Schedule post-mortem

Estimated total rollback time: [Estimate, typically 15 to 60 minutes]

Authority to call rollback: Launch lead (or deputy if launch lead unavailable)

---

Rollback criteria#

Automatic rollback (no debate, just do it)#

• Production error rate exceeds [X]% above baseline
• Critical user flow broken: [specify which flows]
• Database integrity issue detected
• Security vulnerability discovered

Discretionary rollback (launch lead's call)#

• Performance degradation beyond [Y]%
• Significant degradation in [specific business metric]
• Customer-facing error pattern emerging

---

Communication plan#

Internal updates during launch#

• Cadence: Every 15 minutes during cutover
• Channel: [Specific Slack channel / Teams channel / etc.]
• Format: "[Time] - [Step name] - [Status: started / in progress / complete / blocked]"

Customer-facing announcement#

• When: After step 9 (success announce internal)
• Where: [Specific channels: blog post, email, social, etc.]
• Pre-drafted: [Link to draft]
• Approver: [Name]

Status page updates#

• Pre-launch: [Status set to "Maintenance scheduled"]
• During: [Status set to "Maintenance in progress"]
• Post-success: [Status set to "Operational"]
• If issues: [Status set to "Investigating" or "Identified"]

Support team brief#

• Pre-launch brief covers: what's launching, what users may notice, common questions, escalation path
• During-launch updates posted to support channel

---

Verification checklist (first hour)#

• Homepage loads
• Critical user flow 1: [specify] - works
• Critical user flow 2: [specify] - works
• Critical user flow 3: [specify] - works
• Sign-up / sign-in - works
• Payment flow (if applicable) - works
• Email sending - works
• Analytics tracking firing
• Error rate within normal range
• Performance within normal range
• No security alerts triggered
• Search Console shows no critical issues (if SEO-relevant launch)

---

Verification checklist (first 24 hours)#

• No regression in key business metrics: [list specific metrics]
• Error rate stable
• Performance stable
• No accumulating error patterns
• Core Web Vitals stable
• Customer support volume within normal range

---

Contacts#

---

Post-launch#

• Schedule AAR within 1 to 2 weeks
• Document any deviations from runbook
• Capture metrics: rollback rate, time to launch, issues found, etc.
• File improvements to runbook for next launch