Sites rarely fail during peak traffic for exotic reasons. They fail because something that was always slightly undersized finally met a load big enough to expose it. The failures repeat across small business sites with enough consistency that you can prepare for them specifically rather than hoping generally.
A site that handles a hundred visitors an hour and a site that handles a thousand are not the same site with a different number attached. Different things become the bottleneck.
Primo Collab
The database, almost always first
This is the most common failure and the least visible in advance. Your web server can usually serve more concurrent visitors than your database can answer queries for. When the database hits its connection limit, the site does not slow down gracefully. It returns errors.
What makes it worse under peak load specifically:
- Uncached queries that run on every page view rather than once.
- Search and filtering features that scan large tables.
- Plugins that write to the database on every visit, such as analytics, session tracking, and some security tools.
- Abandoned cart and inventory logic that fires repeatedly during checkout.
PHP workers, the limit nobody mentions
Your hosting plan allows a fixed number of PHP processes to run at once. Each visitor requesting an uncached page occupies one until their request completes. When they are all busy, new visitors queue, and then time out.
This is why a site can look fine on a speed test and still fail under load. A speed test measures one visitor. Worker exhaustion is about many visitors at once, and it produces a very specific symptom: the site is either fine or completely unresponsive, with very little in between.
Two things make it dramatically worse: slow pages, because each one holds a worker longer, and uncached pages, because every visitor needs their own.
Caching that quietly excludes the pages that matter
Most ecommerce and membership sites deliberately exclude cart, checkout, and account pages from caching, for good reason: those pages are personal. The consequence is that your highest-traffic, highest-value pages during a sale are also the ones with no caching protection.
Worth confirming before peak:
- Which pages are excluded from your cache, and whether that list is larger than it needs to be.
- Whether your cache actually warms, or whether the first visitor after each purge pays the full cost.
- Whether logged-in users bypass caching entirely, and how many of them you expect.
Third party services, which fail on their own schedule
Your site depends on services you do not control: payment gateways, shipping rate calculators, email providers, review widgets, chat tools, analytics scripts. On a high traffic day, two things happen at once. You use them more, and so does everyone else.
The failure mode that catches people out is not the service going down. It is the service becoming slow. A shipping calculator taking eight seconds to respond does not error. It just holds your checkout open while the customer waits, and then leaves.
Ask, for each external service in your checkout path: if this becomes slow rather than unavailable, what does my customer see?
Email, which fails invisibly
Order confirmations, password resets, and form notifications all go through a sending limit somewhere. Hit it during a sale and the messages stop. Nothing on your site indicates a problem. Customers simply do not receive confirmation, and your support inbox fills with people asking whether their order went through.
Check your provider’s hourly and daily sending limits against a realistic peak order count, not an average day.
What to actually do about it
The fixes are unglamorous and they work:
- Ask your host what your concurrency limit actually is. Not your bandwidth, not your storage. How many simultaneous requests.
- Reduce uncached page weight. Every query you remove from a checkout page buys headroom.
- Confirm the cache covers everything it safely can, and that excluded pages are excluded for a real reason.
- Set timeouts on external services so a slow third party degrades rather than blocks.
- Check your email sending limits against peak volume.
- Load test if the stakes justify it. For a store where a bad day costs real money, a few hundred dollars of load testing in October is cheap.
The mistake to avoid
Upgrading hosting in November as the fix. More resources help, but they raise the ceiling rather than removing the bottleneck, and a migration or plan change during peak season introduces a brand new category of risk at the worst possible time. Find the bottleneck in October, when changing it is a normal piece of work rather than an emergency.