A traffic spike is a strange kind of problem: it’s usually good news wearing the costume of an emergency. A viral post, a press mention, a product launch, or a link from a large site can send more visitors in an hour than a site normally sees in a month — and if the infrastructure isn’t ready, the site goes down at exactly the moment it has the most attention it will ever get. This phenomenon is well-known enough to have its own name: the “Slashdot effect” or “hug of death,” after early cases of small sites collapsing under a sudden surge of visitors from a much larger site.

This guide covers what actually fails first under load, the preparations that meaningfully raise your ceiling before a spike happens, and what to actually do if you’re in the middle of one right now.

1. Why Sites Actually Crash Under Load

“Too much traffic” isn’t a single failure — it’s usually one specific resource hitting its limit first, which then cascades into everything else. Identifying which resource that is (Section 2) matters more than blanket-throwing money at more of everything.

2. What Breaks First, in Order

See our common hosting errors guide for what a 502, 503, or “error establishing a database connection” actually indicates if you’re seeing one of these live right now.

3. Caching: The Single Biggest Lever

Every layer of caching you have in place before a spike hits removes work from the resources in Section 2 — often dramatically. A fully-cached page served to a visitor never touches PHP or the database at all; the web server (or CDN) just returns a stored copy.

• Full-page caching at the server level (or via a caching plugin backed by server-level support) — the biggest single win for a mostly-static or infrequently-updated site
• Object caching (Redis or Memcached) for database query results, which helps significantly even on pages that can’t be fully page-cached (logged-in users, dynamic/personalized content)
• Browser caching headers on static assets, so repeat visitors and multiple page views by the same visitor don’t re-request unchanged files
• CDN-level edge caching (Section 4), which serves cached content from a location near the visitor without hitting your origin server at all

4. Offloading Static Assets to a CDN

Images, CSS, JavaScript, fonts, and video don’t need to be generated dynamically on every request — a CDN serves them from edge locations geographically close to each visitor, which does two things simultaneously: it’s faster for visitors, and it removes that traffic from your origin server entirely, leaving your origin’s capacity for the dynamic requests that actually need it.

See our CDN explainer and CDN hosting guide for how this works in more depth. Most CDN providers also offer some form of full-page edge caching for HTML itself (not just static assets), which pushes the benefit in Section 3 even further from the origin server.

5. Database Bottlenecks

On a dynamic, database-heavy site (a busy WooCommerce store, a forum, a membership site with logged-in activity), the database is frequently the actual limiting factor, even when server monitoring shows CPU headroom to spare.

• Object caching (Redis/Memcached, from Section 3) reduces repeated identical queries hitting the database directly
• Query optimization — a small number of slow, unoptimized queries can dominate database load disproportionately; most hosting panels or database tools can surface a slow-query log
• Connection limits — check your plan’s actual database connection limit against what a spike in concurrent dynamic requests would require
• Read replicas or a managed database tier, on larger/more complex setups, separate read-heavy traffic from the primary database

6. Autoscaling and Hosting-Level Headroom

Beyond caching and offloading, the underlying hosting infrastructure needs actual headroom or the ability to add it quickly. See our autoscaling guide for the deeper technical picture; the short version:

• Shared hosting has a hard resource ceiling shared with other tenants — there’s no autoscaling available, only a manual upgrade to a higher tier or a different hosting category entirely. See our shared vs. VPS comparison if you’re on shared hosting and traffic spikes are a recurring concern.
• VPS hosting can typically be manually resized (more CPU/RAM) with some downtime, but doesn’t scale automatically mid-spike without additional tooling
• Cloud hosting with autoscaling can add capacity automatically as load increases, within configured limits, and scale back down afterward — the most resilient option for genuinely unpredictable spike patterns, at correspondingly more complexity and cost

7. When You Can See the Spike Coming

A product launch, a scheduled press release, or a planned marketing push is a spike you can prepare for specifically, rather than react to.

• Confirm caching is fully configured and actually working (test it, don’t assume)
• Temporarily upgrade hosting resources in advance if your plan allows it, rather than scaling reactively mid-event
• Warm the cache by pre-loading key pages before the traffic arrives, if your caching layer supports it
• Set up real-time monitoring and alerting (see our monitoring guide) so you know immediately if something starts to strain
• Have your host’s support contact information and account details on hand in case you need to escalate quickly
• Consider a queue or waiting-room service for a genuinely extreme, time-boxed event (a major product drop, ticket sale) where demand will predictably exceed capacity for a short window

8. What to Do Mid-Spike, in Real Time

1. Check what’s actually saturated first (Section 2) rather than guessing — your hosting panel or monitoring dashboard should show CPU, memory, and database connection usage in real time.
2. Verify caching is actually active — a caching layer that’s misconfigured or was accidentally disabled is a common, fixable cause of a spike turning into an outage that shouldn’t have happened.
3. Temporarily disable non-essential dynamic features if the platform supports it — related-posts widgets, live comment counts, or other database-heavy elements that aren’t core to the page’s purpose.
4. Contact your host if you’re on shared or VPS hosting and hitting a hard resource ceiling — a temporary emergency resource bump is something many hosts can do faster than a full plan migration.
5. Accept a degraded-but-functional state over a full outage if you have to choose — a slower site that’s still loading is a better outcome than a crashed one, and some caching/queueing systems can be configured to prioritize this trade-off automatically under load.

9. Load Testing Before You Need To

The only way to actually know your site’s real breaking point — rather than guessing from specs on paper — is to test it deliberately, before a real spike forces the question. Load testing tools simulate concurrent visitors against a staging or off-peak production environment and measure where response times degrade or errors start appearing.

10. Preparation Checklist

• Full-page and object caching configured and verified working
• Static assets served through a CDN
• Database slow-query log checked and any obvious bottlenecks addressed
• Real-time monitoring and alerting in place
• Known scaling path identified for your current hosting category (manual upgrade, autoscaling, or a category change)
• Load tested at least once against a staging environment to know your actual ceiling
• A specific mid-spike action plan (Section 8) rather than improvising in the moment
• Host support contact and account details on hand for a planned high-traffic event

11. Frequently Asked Questions