What should I check before a big traffic event?

Read the caching headers on the pages that will receive the traffic, not only the home page. A landing page marked private or no-store is rendered by the origin for every visitor.

Read the CDN's own cache status header on repeated requests. A CDN in front of a site is not the same as a CDN serving it, and a page that misses every time is common.

Check static assets carry long lifetimes with versioned file names, which is what lets them be cached essentially for free.

Look for a cookie being set on every response, which many caches treat as a reason not to store the response at all.

A header that varies the response on something highly variable fragments the cache into near-uselessness.

Personalised pages: account areas, carts, anything reading a session. These are uncacheable by design and are the capacity you actually have to plan.

Search and filter pages, whose parameter combinations make each request effectively unique.

API calls the pages make after load, which frequently carry no caching policy at all.

Form submissions, which by nature cannot be cached.

Knowing this list is what turns the vague question of whether the site will cope into a specific one about a few endpoints.

Page weight and request count multiply by the number of visitors, which matters for bandwidth costs even when everything is cached.

Uncompressed text resources are the cheapest waste to remove before a peak.

Oversized images are usually the largest share of the weight and the easiest to reduce.

A slow server response under normal load will be slower under peak load — measure it now, when there is time to act.

Resources that fail to load are wasted requests that also degrade the page.

Third-party scripts on the critical path: if their provider slows under the same event, your page waits for them.

Embedded widgets — chat, reviews, maps — each an external service with its own limits.

Payment and authentication providers, which are the dependencies whose failure costs most during a sale.

Rate limits on APIs you call, which a traffic peak can reach even when your own servers are fine.

Load critical third parties asynchronously where you can, so their slowness does not become your outage.

An external uptime check on the pages that matter, from outside your own network.

A status page hosted somewhere other than the infrastructure it reports on, so it survives the incident it describes.

A health endpoint the load balancer and the monitoring can read.

A maintenance or overload page that returns the right status code, so crawlers do not index the error page during the event.

And somebody watching, which no configuration replaces.

A load test. An external check reads configuration; it does not generate the peak, and only generating it proves capacity.

Capacity planning for the uncacheable endpoints, which depends on your application and your database.

A rollback plan, since a peak is the worst moment to discover a deployment cannot be reverted quickly.

Agreement with your providers about limits, which lives in contracts and dashboards rather than in headers.