If your website crashes during a traffic spike, the cause is almost always one overloaded part, not the whole site. Find that part before you spend money on a bigger plan. Check that the outage is real, ask your host or developer what is saturated, and put up a simple holding page while the fix happens. This guide covers the first hour of an outage, the usual culprits, how to price the damage and how to get ready for the next big day.
What should I do in the first hour?
Start by confirming the problem. Load the site from your phone on mobile data. Ask a customer or colleague in another city to try. A site that is down for you and fine for everyone else is a local problem.
Next, call your hosting provider or developer and ask a specific question. "Is the site down?" gets you a status page. "Is the database or the server running out of capacity right now?" gets you a diagnosis. If you have no developer on call, your host's support line is the fastest route, and most will tell you whether you hit a resource limit.
While that happens, protect your money. Pause paid ads that point at the broken pages, since every click is a visitor who sees an error. Replace the page with a short holding message that says you are aware of it and when to check back. Send one email or social post to people who were expecting something from you.
Resist the urge to change five things at once. If you upgrade the plan, install a caching plugin and switch providers in the same hour, nobody will know which change helped.
Why does a spike take the site down?
Think of a restaurant. The dining room seats 40, the kitchen can plate 15 meals at a time and one person works the register. A rush of 200 people overwhelms whichever of those is smallest first, and the others sit idle. A website has the same shape. The weakest part sets the limit for everything else.
The usual weak spots look like this.
| Weak part | What it looks like | Typical fix |
|---|---|---|
| Cheap shared hosting | Site slows for everyone at once, host throttles you | Move to a plan with dedicated resources |
| Database | Product pages and search crawl, checkout times out | Fix the slow requests, add caching |
| Checkout and payment steps | Browsing works, orders fail | Simplify what happens per order, queue the extras |
| Too many plugins or add-ons | Each page does a lot of work before it appears | Remove or replace the heavy ones |
| Images and files served from your own server | Server busy sending large files | Use a CDN |
Notice that only the first row is solved by paying more for hosting. The rest are about how the site is built, and a bigger server just moves the ceiling a little higher. We see this pattern often, and our walkthrough of why an API slows down under load shows the same logic from the engineering side.
How much does an outage actually cost?
Work this out before you need it. Take your average revenue for the busy hours of a normal sales day, then scale it up for the campaign you are running. If a launch normally brings in $6,000 an hour at peak, a three-hour outage costs about $18,000 in direct sales, and that is before ad spend wasted on clicks to a dead page and the customers who never come back.
That number is useful in two ways. It tells you how much preparation is worth buying. Spending $3,000 to test and fix a store that could lose $18,000 in an afternoon is easy to justify, while spending $3,000 to protect a $500 day is not. It also lets you have a calm conversation with a developer about priorities, instead of an angry one at midnight.
Will a bigger hosting plan fix it?
Sometimes, and it is the right first move if you are on the cheapest shared plan. Shared plans put many sites on one machine, and the host limits what each one can use. A store that outgrew that plan will crash at much lower traffic than you expect.
If you are already on a decent plan, an upgrade alone often disappoints. A slow database request that takes two seconds on a quiet day takes ten seconds when hundreds of people trigger it at once, and a bigger server only shaves a little off that. The better question for your developer is which requests are slowest and how often they run. If that sounds familiar, our piece on the N+1 query problem explains one very common cause in plain terms.
How do I get ready for the next spike?
Most of the work happens a week or two before the event, not during it.
- Do a load test. A developer or specialist uses a tool to send simulated visitors at a copy of your site, browsing and checking out the way real people do. You get a clear answer about where it slows down and what slowed first. Do it at least a week ahead so you have time to act on what you find.
- Cache what does not change. Product pages, images and the home page can be stored and served without rebuilding them each time. This takes load off the database during the rush.
- Plan for the traffic you want, not the traffic you have. If the campaign works, you will get far more visitors than a normal day. Test for two or three times your best guess.
- Prepare a waiting room or holding page. For a limited drop with a lot of demand, a queue that lets people in at a steady pace beats a site that crashes for everyone. It adds cost, so it only makes sense for events where demand is far above capacity.
- Know who to call. Have a phone number for your host and your developer, and agree beforehand who decides to pause the ads.
If your site depends on slow reports or heavy background work running at the same time as sales, also ask whether that work can move to quiet hours. One scheduled job competing with checkout is a classic cause of a crash that looks like a traffic problem.
When is it worth bringing in outside help?
Handle it yourself if the fix is a hosting upgrade, removing a plugin or turning on a caching feature your platform already offers. Bring in a specialist when crashes repeat after upgrades, when the cause sits in custom code or an integration, or when the next event is large enough that a second outage would hurt the business.
We run a free check for one common cause on the Postgres health check page, which looks at the database side. If the problem is wider than that, our diagnostic is built for finding the weak part before the next big day. For readers who suspect the slow pieces are manual or fragile processes behind the site, our process review looks at that side.