# Get ready for a launch day traffic spike

> Make the app survive a sudden burst of visitors: caching, limits, errors and a rollback plan.

Canonical: https://abacklaunch.com/prompts/launch-day-traffic-readiness
Last updated: 2026-10-26

Version 1.0.

the production site is about to launch, and launch traffic arrives in a burst: hundreds of people in the same hour, most of them on the homepage, the pricing page and sign-up. Find what would slow down or fall over under that burst and fix it, so the first impression is a fast page, not an error.

Site: not given. Find the production URL in the project config, or ask me.

## Ground rules

1. Read before you write. Explore the parts of the codebase this job touches and tell me what is already in place.
2. Plan, then stop. Give me a numbered plan: what you will change, in which files, and why. Wait for my approval before editing anything.
3. Fix things at their source (the shared layout, the config, the generator), not with one-off patches page by page.
4. Keep the project's conventions: its framework APIs, file layout, naming and code style. Add no new dependency without asking.
5. Where something is already done well, say so and leave it alone.

## You will not

- Edit `.env` files, secrets or API keys, or print their values.
- Deploy, push, merge or publish anything.
- Delete data, or run migrations or scripts against a production database.
- Add tracking, third-party scripts or links to any site I did not ask for.
- Change copy, design or behaviour that this job does not need.
- Change database schemas or add indexes without showing me the migration first.
- Load test the production site.

## Your stack

- Framework: Work out the framework, router and build output from the project files (package.json, lockfiles, framework config) before planning, and say which you found.
- Host: Work out where the site is hosted from the config files (vercel.json, netlify.toml, wrangler config, Dockerfile, fly.toml) and say which you found.

## Steps

### 1. Find the hot paths

List the pages and endpoints a launch visitor hits in order: landing page, pricing, sign-up, the first screen after sign-up, and any API those pages call. For each, note what it does per request: database queries, calls to third-party APIs, image processing, server rendering.

### 2. Cache what is the same for everyone

- Public pages that do not change per visitor should be static or cached at the edge, with a sensible `Cache-Control` (for example `public, s-maxage=300, stale-while-revalidate=86400`). Make sure nothing personal (a signed-in header, a cookie banner state) is cached with them.
- Static assets (scripts, styles, fonts, images) should be fingerprinted and served with a long `max-age` and `immutable`.
- Data that many visitors read (counts, featured lists, pricing) can be cached in memory or in the framework's data cache for a short time.

### 3. Remove the slow parts

- Look for N+1 queries, queries without an index on the columns they filter or sort by, and work done on every request that could be done once.
- Third-party calls on the critical path (analytics, enrichment, AI calls) should have a timeout and must not block the page from rendering.
- Large images on the landing page should be resized, in a modern format, with width and height set.

### 4. Protect the endpoints that cost money or can be abused

Sign-up, login, password reset, contact forms, and any endpoint that sends email or calls a paid API need a rate limit per IP and per account, with a clear 429 response. If the project already has a rate limiter, reuse it.

### 5. Fail gracefully

Make sure there is a friendly error page for 500s and a real 404 page, that a failed third-party call shows a fallback instead of a blank screen, and that errors are logged somewhere I can read (the existing logging or error tracking; propose one if there is none, do not add it without asking).

### 6. Write the launch day runbook

Add a short `LAUNCH.md` (or a section in the existing docs) with: how to check the site is up, where to read logs and errors, how to roll back to the previous deploy on the current host, how to scale up if the host allows it, and who to contact. Keep it to one screen.

## Done means

- [ ] Every public page a launch visitor sees is cached or static, and nothing personal is cached.
- [ ] No hot path makes an unbounded or unindexed query, and third-party calls have timeouts.
- [ ] Sign-up, login and anything that sends email or calls a paid API are rate limited.
- [ ] 500 and 404 pages exist and return the right status codes.
- [ ] A one-screen launch runbook explains how to check health, read errors and roll back.

## Report back

When you finish, give me:

- what you changed, file by file;
- anything you skipped, and why;
- anything I must do by hand (DNS records, dashboards, accounts, deploys);
- how to check each change on the live site.

## Related

- [Pre-launch audit with a prioritised fix list](https://abacklaunch.com/prompts/pre-launch-audit)
- [Analytics and UTM attribution for launch day](https://abacklaunch.com/prompts/launch-analytics-attribution)
- [From waitlist to launch day email](https://abacklaunch.com/prompts/waitlist-launch-email)