Production readiness checks

Checks whether errors are reported, handled and logged safely, and sets up an error tracking service when asked.

Checks whether the database and uploaded files are backed up, whether hosting plans could pause or drop the project, and whether anything alerts the owner when the site goes down.

Checks that a project is configured to run correctly in production: environment variables, build health, host limits, domain and callback addresses, and email delivery setup.

Finds code that turns a slow or failing service, a second server instance or a restart into an outage or lost work: outside calls with no timeout, background work that is silently dropped, retry storms, failed jobs that vanish, scheduled jobs that run twice, in-memory state on multi-instance hosts, no graceful shutdown and memory that grows without limit.

Finds what makes deploying a new version risky: shared caches that serve one user's page to another, database changes that break the running or previous version, open browser tabs that break after a deploy, live connections the host cuts, risky features with no off switch and no check after deploy.

All reliability checks, plus production checks that `/launch-check` does not run (see below). `/launch-reliability basic` skips them

Backups, plan risks, uptime monitoring

Error handling and logging

Missing or unsafe environment variables

Build settings, host limits, scheduled jobs, rollback

HTTPS, redirects, callback addresses, email delivery records

Calls with no timeout, background work the host drops, retry storms, lost jobs, cron jobs that run twice, in-memory state, no graceful shutdown, memory that keeps growing

Caches that show one user's page to another, database changes that break the running version, open tabs that break after a deploy, no off switch for risky features

Installs error tracking