How to survive a traffic spike

A traffic spike is a different problem from everyday slowness, and it needs a different response. A site that is normally perfectly adequate can still struggle badly under a sudden, short-lived surge, because the resources that comfortably handle typical daily traffic are not necessarily enough for several times that volume arriving in a compressed window. What actually breaks, and what actually helps, is not the same list as for ordinary day-to-day speed.

What actually happens during a spike

Every additional concurrent visitor means another request the server has to process at the same time as everything else already in progress. Below a certain volume this is invisible — the server has spare capacity and handles it without anyone noticing. Past that point, requests start queuing behind each other, response times climb for everyone rather than just the newest arrivals, and if the surge is severe enough, the account can hit hard resource or connection limits and start failing requests outright rather than just answering them slowly.

The single biggest lever: caching

If the page attracting the surge is not already cached, every one of those extra visitors triggers the full assembly process — database queries, template rendering — independently. That is by far the most expensive way to serve a page that looks identical for almost everyone requesting it. Page caching turns a spike of a thousand expensive requests into one expensive request followed by nine hundred and ninety-nine cheap ones, which is the single most effective thing most sites can do, and the one most worth confirming is actually working before an expected surge arrives.

Let a CDN take the static weight off your server entirely

Images, stylesheets and scripts served from a CDN's cached edge locations do not touch your origin server at all once cached — every one of those requests handled at the edge is one less request your server has to answer during the exact moment it is under the most pressure. What a CDN does, and when you need one covers this properly; during a spike specifically, it is the difference between your server handling only the dynamic, uncacheable part of the load and it handling everything at once.

Preparing ahead of a known event

Some spikes are foreseeable — a planned launch, a scheduled promotion, a press mention with a known date. That advance notice is worth using:

1. Confirm caching is actually working, not just configured

   Check a page is genuinely being served from cache under normal conditions before assuming it will hold up under a surge.

2. Make sure a CDN is switched on for images and static assets

   Confirm it, rather than assuming a setting from months ago is still active.

3. Compress and check image weight on the specific pages expecting traffic

   A heavy, uncompressed hero image is a bigger problem under load than under normal traffic, because every extra byte is now competing for bandwidth with far more concurrent requests.

4. Check current resource usage against typical levels

   Your control panel's usage panel shows where the account normally sits, which gives you a baseline for how much headroom exists before the event.

5. Have a simple, static holding version of the most critical page ready

   For the highest-risk scenario — a launch page or a landing page central to the event — a simple static version that needs no database at all is the most resilient thing you can serve, if the dynamic version is at real risk of being overwhelmed.

Do not overlook third-party services as a point of failure

A surge does not only put load on your own hosting — it also increases the number of calls your site makes to anything external it depends on: a payment gateway, a mapping widget, a review or booking service, an email delivery API. If one of those services slows down or rate-limits requests under the sudden extra volume, the effect on your own site can look identical to your own server struggling, even though your hosting is coping perfectly well. Worth checking during any period of unusually high traffic: is a specific request to your own server slow, or is the whole page waiting on a script or embed pulling in something from elsewhere.

If a spike happens without warning

An unplanned spike — a post going unexpectedly viral, an unexpected mention somewhere with real reach — leaves less time to prepare, but the same priorities apply in the moment: confirm caching is active on whichever specific page is receiving the traffic, since that single fix has the largest effect of anything available quickly. If the account is genuinely being overwhelmed rather than just running warm, that is exactly the kind of short-term resource pressure worth contacting support about immediately, since a temporary constraint during a known event is a different conversation than ordinary day-to-day capacity.

What a spike does and does not tell you about your normal plan

Running a store specifically expecting a seasonal or promotional surge has its own considerations beyond the general ones here — see preparing a store for a sales rush for the parts that are particular to checkout and cart behaviour under load.