shipping-and-launch

A production launch checklist covers six areas: code quality (tests, lint, reviews), security (dependency audits, headers, rate limiting), performance (Core Web Vitals, N+1 queries), accessibility (WCAG 2.1 AA), infrastructure (env vars, migrations, health checks), and documentation. All sections must pass before deploying.

Deploy with the flag off, enable for internal team first, then canary to 5% of users, and increase through 25%, 50%, and 100%. Monitor error rates, P95 latency, and business metrics at each stage for 24-48 hours, advancing only when thresholds stay green.

Roll back immediately when error rate exceeds 2x baseline, P95 latency rises more than 50%, user-reported issues spike, or data integrity or security problems appear. Feature flag rollbacks take under a minute; redeploying a previous version takes under five minutes.

Monitor application metrics (error rate, p50/p95/p99 latency, request volume), infrastructure metrics (CPU, memory, database pool, queue depth), and client metrics (Core Web Vitals, JavaScript errors). In the first hour, verify the health endpoint, error dashboards, and the critical user flow manually.

An error budget gate uses your SLO's allowed failure fraction to decide if shipping is safe. Above 20% budget remaining you ship normally, 0-20% means slow rollouts only, and exhausted budget freezes feature work until reliability is restored.

Common red flags include deploying without a rollback plan, no monitoring in production, big-bang releases without staging, feature flags with no owner or expiration, and shipping when the error budget is exhausted. Assuming staging success guarantees production success is another frequent failure.