Launch control room
A launch sequence that can actually stop
Assign the owner before the release window. Evidence must be available to the person making the go/no-go decision.
- T−24 hours01
Freeze scope and name the release
OwnerRelease owner
EvidenceExact commit, included changes, known limitations and approved acceptance criteria
- T−4 hours02
Verify domains, configuration and vendor capacity
OwnerDeployment owner
EvidenceEnvironment variables, DNS, certificates, quotas, billing and external status reviewed
- T−1 hour03
Protect data and rehearse rollback
OwnerData or operations owner
EvidenceRecent backup where applicable, restore path and previous deploy available
- T−15 minutes04
Run critical journeys on the candidate
OwnerProduct acceptance owner
EvidencePrimary, invalid, denied and failed paths pass in a production-like environment
- T+5 minutes05
Verify the production artifact
OwnerRelease owner
EvidenceExpected version, canonical domain, headers, assets, jobs and integrations observed
- T+30 minutes06
Read user-outcome and system signals
OwnerOn-call owner
EvidenceTraffic, latency, errors and one real or synthetic critical journey are healthy
- T+24 hours07
Close or roll back the release
OwnerProduct and operations owners
EvidenceIncidents, support, cost, analytics and known limitations reviewed
Green CI is one input
Deploy the version you reviewed, then verify the environment
Generated projects often accumulate dashboard configuration, preview-only assumptions and copied environment variables. Pin the release to a commit and verify the deployed version instead of trusting that the newest build corresponds to the accepted change.
A rollback is not ‘redeploy later’. Define which version, data compatibility and routing action can restore service, who may trigger it and when forward-fixing is no longer justified.
- Use organization-owned production access
- Keep secrets out of source and client bundles
- Make database changes backward-compatible where possible
- Announce and record the final go/no-go decision
Decision matrix
Distinguish build, deploy and launch evidence
These stages answer different questions and should not collapse into one green indicator.
| Stage | Question | Evidence | Common false confidence |
|---|---|---|---|
| Build | Can the source produce an artifact? | Locked dependencies, tests and build output | Compilation is treated as product correctness |
| Deploy | Did the artifact reach the intended environment? | Deployment ID, configuration and health | Preview and production are assumed identical |
| Launch | Can intended users complete critical outcomes? | Production journey and observable signals | Homepage availability represents the whole service |
| Operate | Can owners detect and recover failure? | Alerts, runbook, backup and rollback exercise | A provider dashboard replaces application ownership |
Applied example
Launch failure: the preview passed with the wrong environment
The candidate works in preview because it uses a test database and permissive authentication callback. Production deploys successfully but login loops on the canonical domain.
- The build and deployment are technically green.
- The production configuration violates the real user journey.
- A production-domain smoke test would catch the issue before broad announcement.
- The stop condition should trigger rollback rather than prompting changes directly in production.
Plain answers
Deployment questions
Should every small update use this entire checklist?+
Scale ceremony with risk, but retain version identity, critical evidence, an owner and a recovery decision for every production change.
Is automatic deployment unsafe?+
No. Automation can improve consistency. The pipeline still needs protected inputs, acceptance gates, production verification and a rollback path.
How long should we monitor after launch?+
Choose a window that covers the likely traffic and background jobs. Some failures appear immediately; billing cycles, scheduled work or low-volume journeys may require longer observation.