Production Go-Live Readiness Checklist

When to Use This Checklist

Use this checklist in the final phase before a service serves real production traffic. It is most valuable for first launches, major version cutovers, and re-platforming events such as moving a workload onto Kubernetes. The goal is to remove surprises from go-live by confirming that scaling, observability, security, data safety, and rollback are all proven before users arrive.

How to Use This Checklist

Work through the items in order during the days leading up to launch. Treat every required item as a gate: if it cannot be satisfied, the go-live should be paused. Assign each item an owner and a verification artifact (a screenshot, a pipeline run, a runbook link) so that sign-off is evidence-based rather than verbal. The optional items, such as canary routing, are strongly recommended for high-traffic systems but may be skipped for low-risk internal tools.

Hold a short go/no-go meeting once the checklist is complete. The meeting should review only exceptions and open risks, not re-litigate items already verified. Record the decision and the named approver.

What Good Looks Like

A healthy go-live has a frozen, tagged artifact that has already passed the full pipeline in a production-like staging environment. Dashboards and SLO burn-rate alerts are visible and quiet. The rollback path has been executed at least once and timed, so the team knows exactly how long recovery takes. Database migrations are backward compatible, meaning the previous application version can still run against the new schema. On-call engineers are briefed, and the abort criteria are written down and unambiguous.

When these conditions hold, the team can launch with a canary or feature flag, watch the golden signals, and ramp exposure with confidence. If anything degrades, the documented rollback returns the system to a known-good state quickly.

Common Pitfalls

The most common failure is treating rollback as theoretical. Teams that have never executed a rollback often discover during an incident that it is slow, manual, or breaks on schema changes. Another frequent gap is shipping a backward-incompatible migration alongside the application, which makes rollback impossible without data loss. Missing or noisy alerting is also dangerous: if dashboards are not trustworthy before launch, they will not be trusted during an incident.

Finally, avoid go-lives that depend on a single person's tribal knowledge. If the runbook is incomplete or lives only in someone's head, the launch is fragile. Capture every manual step.

Related Resources

Pair this checklist with blue-green or canary deployment practices to limit blast radius, and with SLO-based alerting so you measure user impact rather than raw infrastructure metrics. Feature flags let you decouple deployment from release, giving an instant kill switch independent of the deployment pipeline.