Will your app survive the campaign?

The day you paid for traffic

A launch, a press mention or a paid campaign can send more visitors in an hour than your app sees in a normal week. If the app slows down or falls over, you could pay for every click that lands on an error page, and the people who bounced may not come back for a second look.

Most launch-day failures are not exotic. A database runs out of connections, a hidden account limit is hit, an email provider throttles sign-ups, or a last-minute deploy breaks checkout and nobody knows how to undo it. Each one can be checked a week ahead.

This guide is the list. Start it 7 to 10 days before launch, and keep the last section for the day itself.

1. Capacity: know your number

Estimate the peak. Take your expected visitors for the busiest hour (ad budget divided by cost per click, email list size times expected open rate, and so on) and multiply by 3 for safety. Example: 20,000 expected visitors over a day, with 25% in the busiest hour, is 5,000 visitors per hour. Plan for 15,000.

Test it. Run a load test (a script that simulates many users at once) against a staging copy that matches production, or against production at a quiet hour with care. Open-source tools such as k6 or Locust can script the real path: landing page, sign-up, the main action, checkout.

Watch during the test:

• Response time of the slowest 5% of requests (often shown as p95), not just the average.
• Error rate.
• Database CPU, memory and connection count.
• Any queue or background job backlog.

Good looks like: at your planned peak, p95 response time stays under about one second for key pages and errors stay near zero.

Common fixes:

• Database connections. Each app server opens its own pool of connections, and databases have a hard maximum. A connection pooler (for example RDS Proxy on AWS, or the pooler built into Supabase) lets many app servers share fewer connections.
• Caching. Put static files and public pages behind a CDN (a content delivery network that serves copies from locations near the user), so most traffic never reaches your servers.
• Autoscaling. If you use it, check the maximum number of servers it is allowed to add. A maximum of 2 is not autoscaling.
• Slow queries. The load test usually exposes one or two. Add the missing index before launch.

2. Limits you did not set

Cloud accounts and third-party services have limits that only show up under load.

• Cloud quotas. In AWS, open Service Quotas and check limits that matter for your setup, such as the number of instances you can run, Lambda concurrency (how many function copies may run at once) and load balancer limits. In Google Cloud, check IAM & Admin, then Quotas. Increases can take days to approve, so ask early.
• Your hosting platform's plan limits on bandwidth, function run time and concurrent builds.
• Email. Your sending provider's daily and per-second limits, plus a verified sending domain, so sign-up and receipt emails do not land in spam on the busiest day.
• Payments. Your payment provider's rate limits and any fraud rules that might block a sudden wave of new cards. Run one real low-value purchase end to end.
• AI and other APIs. Rate limits and spend caps on any API your app calls per user action. A cap that stops spend also stops your app.

3. Alerts: you hear first, not your customers

For many small teams the first alert is a customer email. On launch day that is too late.

• Uptime check from outside. A monitor that loads your homepage, login and checkout every minute from more than one location, and alerts on failure. Most cloud providers and many independent services offer this.
• Error-rate alert. Alert when 5xx errors (server errors) pass a small threshold, for example 1% of requests over 5 minutes.
• Database alerts on CPU, free storage and connection count.
• Spend alert. A budget alert on your cloud account, so a runaway autoscaling group or a leaked key during the noise of launch is noticed within hours.
• Routing. Alerts go to a phone, not only an inbox, and a named person is on call for launch day and the night after.
• Test the alert. Trigger one on purpose before launch and confirm the right phone rings.

4. Rollback: undo in minutes

The riskiest change on launch day is the one you make that morning.

• Freeze code changes 24 to 48 hours before launch, except fixes for real problems.
• Know the rollback. Write down the exact steps to return to the previous version: on many hosting platforms this is a "promote previous deployment" button; with containers it is redeploying the previous image tag. Practice it once in staging and time it.
• Database changes are the hard part. Run migrations well before launch day, and prefer changes that keep the old version of the app working (add a column first, remove the old one later).
• Feature flags (switches that turn a feature on or off without a deploy) let you turn off a broken feature in seconds instead of rolling back everything.
• Backups. Confirm a fresh, restore-tested database backup exists from the day before. See our backup restore test guide.
• DNS. If you might need to move traffic, lower the DNS TTL (how long other systems cache your address) a day or two ahead.

5. Status page and the message plan

When something does go wrong, a clear message keeps trust while you fix it.

• Set up a simple status page on a separate service and domain, so it stays up when your app does not.
• Pre-write three short messages: "investigating", "identified, fixing", "resolved". Plain words, no blame, a time for the next update.
• Decide who posts updates, and where: status page, social account, in-app banner.
• Have a fallback for the campaign itself. Know how to pause the ads or the email send within minutes if the app is down, so you stop paying for traffic that cannot convert.

The printable checklist

After the launch

Write down the peak you reached, what slowed down first, and anything you would fix before the next one. That page makes the next launch half the work.

The 2-minute check covers outages, alerts and the other quiet gaps, with one fix for each.

Want a second pair of eyes?

The free review looks at your setup with view-only access and tells you, in plain words, what is most likely to break first under load and what to fix before you spend on traffic.

Sources

• AWS Service Quotas
• Google Cloud: View and manage quotas
• Amazon RDS Proxy
• Supabase: Connect to your database (connection pooling)
• Amazon CloudWatch Synthetics canaries
• Google Cloud: Uptime checks
• Grafana k6 documentation
• Locust documentation

From keelops.co/launch-day-checklist. Free to print and share.