My app broke right after launch. What do I do first?

My app broke right after launch. What do I do first?

Stop the damage first, diagnose second. Roll back to the last working deployment if you can, turn off the feature or signup that is failing, rotate any key that may have leaked, and tell affected users plainly. Then read the logs for the first error, fix that one thing and add the monitoring you did not have.

What is really going on

Launch day is the first time an app meets real users, real volume and real mistakes. Everything that was never tested because there was one user (you) is tested at once: concurrency, rate limits, free tiers, email limits, forms filled in by people who do not think like you.

The temptation is to start fixing the first thing you see. The better order protects people before it fixes code. Stop what is causing harm, preserve evidence, communicate, and only then debug. A fast rollback that restores service is almost always better than a clever fix made under pressure.

The second mistake is fixing symptoms in sequence. A launch crisis usually has one or two root causes (a connection limit, a missing secret, an unbounded loop calling a paid API) that show up as ten different errors.

What usually breaks at launch, most common first

1. The database runs out of connections

   How to tell Errors such as "too many connections" or timeouts that start as traffic rises and clear when it drops. Serverless functions each open their own connection, and a direct database connection allows few.

   The fix Switch application traffic to the provider's pooled connection string, reduce the connections each function holds and add an index for the slow query that holds them open.

2. A third-party limit is hit

   How to tell Errors with status 429, or failures that begin at a round number. An AI model API, an email provider or a maps service has a rate or spend limit on the account you are using.

   The fix Raise the limit or move to a paid tier, add retries with backoff and a queue for the non-urgent calls, and show users a clear message rather than a blank failure.

3. Costs run away

   How to tell The provider dashboard shows spend climbing faster than signups. A loop, a missing cache, a bot hitting an unauthenticated endpoint or users with no per-account limit can multiply API calls.

   The fix Set spend caps and alerts at the provider, add per-user rate limits, and require login before any call that costs money.

4. Signup or checkout fails for strangers

   How to tell Your own accounts work and new ones do not. Confirmation emails do not arrive, OAuth redirects are wrong, a payment webhook is not firing, or row level security blocks a new user's first write.

   The fix Reproduce as a brand-new user on production, fix that path first, and contact people who failed so they can finish. Our symptom pages cover webhooks, OAuth, email and RLS.

5. Abuse and spam arrive within hours

   How to tell A flood of fake signups, bot submissions on forms, scraping, or an open endpoint used by someone else's script.

   The fix Add rate limiting and bot protection on signup and forms, require email confirmation, and close any endpoint that does not need to be public.

6. Nobody knows what is failing

   How to tell You learn about errors from users. There is no error tracking, no uptime check and the only logs are in the host's dashboard.

   The fix Add error tracking and an uptime check today. They take under an hour, and they turn the next incident from a surprise into an alert.

How we diagnose it

1. Stop the damage. Roll back to the last good deployment, disable the failing feature or pause signups, and rotate any credential that may be exposed. Restoring service comes before understanding.
2. Tell people. Post a short, honest status for affected users: what is wrong, what you are doing and when you will update. Silence reads as negligence.
3. Find the first error. Read the production logs from just before the first user report. The earliest error is the cause; the later ones are fallout.
4. Find the shared root cause. Group the errors by what they have in common: one dependency, one table, one endpoint, one limit. We usually find one or two causes behind many errors.
5. Fix, verify as a stranger, then monitor. Ship the smallest fix, test it as a new user on production and add the alert that would have told you first.

What fixing it changes

• Service is restored and the failing path works for a brand-new user on production.
• Connection, rate and spend limits are understood and have headroom, with alerts before they are hit.
• Error tracking, uptime checks and a status channel exist.
• Abuse paths are closed with rate limits and confirmation steps.
• People who failed during the incident are contacted and helped to finish.

When you do not need us

If one clear cause explains everything and a rollback fixed it, you may be done once you add monitoring. Bring in help when the app is still failing, when you cannot tell whether data was exposed, when money is being lost or when you have fixed three things and a fourth appeared.

Your next step

Straight answers