The Production Readiness Checklist We Run Before Every Launch

Nearly every production incident we have been called in to fix was preventable by a check that takes minutes. Not clever architecture — routine verification that got skipped because the launch date was close. This is the list we run before handing anything over.

Backups: Verified, Not Configured

Everyone configures backups. Far fewer have ever restored one. An unverified backup is a belief, not a safeguard. Restore to a scratch environment, confirm the data is complete and current, and write down how long the restore took — that number is your actual recovery time, and it is usually longer than anyone assumed.

Monitoring That Wakes Someone Up

Uptime checks from more than one region, error tracking with alerts routed to a person rather than a dashboard nobody opens, and log retention long enough to investigate something reported three days late. Then test it: deliberately break something in staging and confirm the alert actually arrives. Untested alerting fails silently, and you find out during the incident.

The Security Basics

HTTPS everywhere with automatic renewal — expired certificates remain a leading cause of embarrassing outages. Security headers set. Rate limiting on authentication and form endpoints. Dependencies audited and patched before launch rather than after. Secrets in environment variables, never in the repository, and rotated if they ever were. Admin surfaces behind authentication and, where practical, IP restrictions.

Performance Under Real Conditions

Test on a mid-range Android phone on a mobile connection, not a developer laptop on office fibre. Check Core Web Vitals on the slowest important page rather than the homepage. Confirm images are sized and served in modern formats, that caching headers are set, and that a CDN is actually serving the traffic you think it is. Then load-test at a realistic multiple of expected peak — the useful outcome is discovering which component fails first.

The Rollback Path

Before deploying, know exactly how to undo it, and confirm someone other than the person who wrote the code can execute that. Database migrations deserve particular attention — many are not reversible without a restore, which puts you back at the first item on this list. Write the rollback plan down. During an incident nobody reasons well from memory.

Who Answers at 2am

The most common gap is not technical. Nobody has agreed who is responsible when something breaks outside working hours, or what counts as urgent enough to call. Decide it before launch, in writing. A system nobody owns is a system nobody fixes.