Launch day

Morning: the go-live checklist

1. Confirm the go/no-go one last time. Any new critical blocker since the preflight? If yes, it's a no-go — the criteria don't expire.
2. Run the staging→production checklist from your written runbook: DNS (if cutting over today — see the DNS playbook), environment variables, secrets, migrations, deploy, smoke tests. Check each item off as you go, in order.
3. Smoke-test production like a stranger: homepage, signup, checkout, contact form, password reset. On desktop and on your phone.
4. Open your monitoring posts: uptime dashboard, error tracking, analytics real-time view. These stay open all day.
5. Confirm alerting reaches you with one final test alert.

Set your monitoring posts

You need four views open, and a rule for each:

• Uptime: is the site reachable? Any alert here is drop-everything priority.
• Errors: error rate and new error types. A spike in a new error type means the deploy broke something specific — investigate before it compounds.
• Conversions: signups, checkouts, or lead submissions in real time. Traffic with zero conversions is a signal, not a coincidence — something in the funnel is broken.
• Feedback channel: support inbox, contact form destination, social mentions. Real users find bugs your tests didn't.

The comms sequence

Launch comms were drafted during the preflight. Today you execute them in order:

1. Verify first, announce second. Nothing goes out until the smoke tests pass on production. An announcement linking to a broken site is worse than a late announcement.
2. Publish the changelog / launch notes on your own site first — it's the canonical record everything else links to.
3. Send to your warmest audience first (email list, community, existing users). They forgive early wobbles and report bugs kindly.
4. Then go wide: social posts, launch platforms, press. Space these out — a staggered rollout gives you time to catch issues between waves.
5. Stay present where you announced. Reply to early comments and questions quickly; the first hours set the tone for how the launch is perceived.

Triage roles

On a team, assign these explicitly. Solo, rotate through them consciously — the point is that every report has an owner and nothing sits unowned:

• Watcher: eyes on dashboards, calls out anomalies.
• Responder: investigates and fixes (or calls the rollback).
• Communicator: owns outward updates — status page, social replies, support responses. One voice, no contradictions.

Every incoming report gets a severity on arrival: S1 (site down, checkout broken, data issue — drop everything), S2 (major feature broken, workaround exists — fix today), S3 (minor, cosmetic, nice-to-have — log it for the week). If everything feels S1, nothing is — force the ranking.

When to pause the rollout

Pausing is a sign of discipline, not failure. Pause announcements and consider rollback when:

• Uptime monitoring fires, or error rates spike 10× baseline.
• Conversions flatline while traffic is healthy — the funnel is broken somewhere.
• A data-integrity issue appears (wrong data shown, duplicate charges, lost submissions).
• You hit a rollback trigger from your rollback runbook.

When you pause, say so publicly and briefly: "We're pausing the rollout to fix [thing]. Back shortly." Silence during an incident reads as chaos; a short honest note reads as competence.

End of day: the review

Before you close the laptop:

• Write down what broke, what the severity was, and what fixed it — even if "nothing broke."
• Confirm monitoring and alerting are still armed for the night, and the on-call path is clear.
• Move every S3 and deferred S2 into the post-launch week backlog so nothing evaporates.
• Note one thing to improve about the launch process itself. There's always one.