How to Prevent a Website Crash During Traffic Spikes and Sales

How do you prevent a website crash during a campaign traffic spike?

A website crash during a campaign happens when a sudden traffic spike exhausts the server's CPU, memory, PHP workers or database capacity, so pages stop loading. To prevent it, you turn on caching and a CDN, fix slow queries, run a load test, set up monitoring and, if needed, add hosting capacity before launch day.

We are Talha Aslan and team, a digital marketing and web team. We are not a hosting company. That is why we base the settings and commands in this guide on official documentation from PHP, MySQL, nginx, MDN and Google Search Central. Our goal is simple: help a store owner planning a sale, or a developer running their own VPS, decide what to do and in which order.

Turning visitor numbers into a capacity estimate is a separate topic, and we cover it in a companion article. Here we focus on the prevention playbook instead: why sites go down, the order of fixes, testing, monitoring, a rollback plan and a launch day checklist.

Why does campaign traffic take a site down?

On a normal day, visitors arrive spread across the hours. A campaign changes that. An email blast, a push notification, a flash sale start time or an influencer post sends people to your site within the same few minutes. For the server, the daily total matters far less than the number of requests it must handle at the same moment.

Every request holds a resource: a PHP worker, a database connection, a slice of memory. Once those resources run out, new requests wait in line. As the line grows, response times climb. Then timeouts start, along with 502, 503 and 504 errors. In short, a website crash rarely happens in one instant; first the site slows down, then the errors pile up.

Campaign traffic also hits your most expensive pages. Cart, checkout, search and filter pages are personal, so they bypass the page cache. As a result, every visitor puts direct load on the database. On top of that, ad visitors are impatient. If a page hangs for a few seconds, they leave, and you still pay for the click.

Which bottlenecks most often cause a website crash?

A crash rarely has a single cause. Usually the weakest link in the chain breaks first. The table below sums up the most common bottlenecks, their symptoms and the first fix to apply before a campaign.

On shared hosting, your plan also has its own limits for CPU, memory, I/O and concurrent processes. Your site can return errors once you hit those limits, even when the physical server has headroom. So ask your provider about your plan limits well before the campaign.

Why do PHP workers usually choke first?

On PHP sites such as WordPress, WooCommerce or Laravel, each dynamic request uses a PHP-FPM worker. According to the PHP manual, pm.max_children sets the limit on the number of simultaneous requests the pool will serve. In other words, when every worker is busy, the next visitor waits.

The first instinct is to raise that number. However, every worker consumes memory. If the worker count times the average memory per worker exceeds free RAM, the server starts swapping and slows down even more. Therefore, the right move is to cut the load per request first, and only then size the worker count to your memory.

; PHP-FPM pool file, example skeleton
pm = dynamic
pm.max_children = (based on your memory math)
pm.max_requests = (guard against memory leaks)
pm.status_path = /fpm-status

The manual describes pm.max_requests as the number of requests each child handles before it respawns, which helps with memory leaks in third party libraries. pm.status_path turns on a live status page, so you can watch how many workers are busy during the campaign. Restrict that status page to your own IP address.

In what order should you tackle website crash prevention?

Order matters, because cheap and effective fixes should come before expensive ones. Buying a bigger server for a poorly built site only postpones the problem. We recommend this sequence:

1. Turn on page and object caching, and keep personal pages out of the cache.
2. Serve static files through a CDN with long cache headers.
3. Reduce image and JavaScript weight, and drop unneeded third party tags.
4. Find slow database queries and add missing indexes.
5. Simplify the campaign landing page and cache live counters.
6. Plan a waiting room or request rate limiting if you need one.
7. Run a load test on a staging copy.
8. Set up monitoring and alerts.
9. Take a backup and write down the rollback plan.
10. Add hosting capacity ahead of time, based on test results.
11. Align the ad and email schedule with the tech team.

Start this list at least a few weeks before the campaign. If testing and capacity upgrades slip to the last day, you will have no time left to fix what they reveal.

How do page caching and object caching cut server load?

A page cache stores the finished HTML of a page and hands it to the next visitor without touching PHP or the database. That means campaign pages, product pages and category pages, which look the same for everyone, put almost no load on the server. On WordPress, a caching plugin does this job; on the server side, you can use Varnish or the nginx cache.

An object cache keeps database query results in memory. Even personal pages run fewer queries that way. We explain the difference between Redis and Memcached in how caching works with Redis and Memcached. Also check your OPcache settings, so PHP does not recompile your code on every request.

Caching has two traps, though. First, if cart, checkout or account pages end up in the cache, one customer may see another customer's data, so always exclude them. Second, the old price can linger in the cache when the sale starts. For that reason, write down in advance how and in which order you will purge the cache at launch time.

What do you gain by moving static content to a CDN?

When a page loads, most requests go to images, CSS, JavaScript and fonts. These files are identical for every visitor. A CDN delivers them from servers close to the visitor, so your origin server only deals with dynamic requests.

For a CDN to work well, you need the right Cache-Control headers. MDN recommends this pattern for static files that carry a version or hash in their file name:

Cache-Control: max-age=31536000, immutable

According to the same page, s-maxage sets freshness only for shared caches such as a CDN. Meanwhile, stale-if-error lets a cache reuse a stale response when the origin returns 500, 502, 503 or 504. During a campaign, that directive can hide a short server hiccup from visitors. Still, confirm in your CDN's own documentation that it supports the directive.

Finally, if the CDN setup requires a DNS change, make it days before the campaign. DNS propagation and SSL certificate reissuing can take time.

How do you trim image and JavaScript weight before a campaign?

The heavier the page, the more work the server and network do for the same traffic. A slow page also loses the visitor you paid for. We cover how speed affects search visibility in how site speed affects SEO, and how it affects revenue in ecommerce page speed and sales.

Quick wins before a campaign include:

• Convert images to modern formats and serve them at their real display size.
• Use lazy loading for images below the fold.
• Remove unused plugins and page builder blocks.
• Trim third party tags such as live chat, heatmaps and duplicate pixels.
• Skip autoplay video and heavy sliders on the campaign page.

For a step by step look at what to defer or remove on the script side, see our guide on how JavaScript affects site speed. After every change, measure again. In practice, you want to move forward on results, not on guesses.

How do you check database queries and indexes?

Cart, checkout and search pages skip the cache and go straight to the database. Under heavy load, one slow query can tie up every connection. That is why you need to find slow queries before the campaign, not during it.

The MySQL documentation shows how to turn on the slow query log at runtime:

SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 2;
SET GLOBAL log_queries_not_using_indexes = 1;

The threshold here is only an example, so pick one that fits your site. The documentation also points to mysqldumpslow, which summarizes long log files and surfaces the slow queries that repeat most often. Next, run suspicious queries with EXPLAIN and check whether they use an index.

Scheduled jobs are another common source of locks. A stock import, a report export or a bulk price update can lock tables if it runs during the campaign window. So move those jobs outside the campaign hours. If you are on shared hosting and cannot run these commands, ask your provider for a slow query report.

How can third party services trigger a website crash?

Even a healthy server can freeze because of an outside service. Payment gateways, shipping rate lookups, SMS verification, invoicing or stock sync can all slow down under campaign load. Every request that waits on them keeps a PHP worker busy. Eventually the workers fill up, and visitors see an error page even though the root cause sits elsewhere.

You can guard against this kind of website crash in three ways. First, give every outbound call a short, explicit timeout, so a stuck service does not hold a request forever. Second, push order confirmation emails, invoice generation and notifications into a background queue. That way, the checkout step responds quickly.

Third, add the status pages of your critical providers to your launch day monitoring list. It also helps to tell your payment and shipping providers about the campaign date. In short, preparation that ignores any link in the chain stays incomplete.

How do you keep the campaign landing page light?

The landing page takes the first hit of campaign traffic. So it should be cache friendly, simple and free of personalized blocks. When everyone sees the same content, the page comes straight from the cache or the CDN.

Common mistakes include a live stock counter that queries the database on every load, a "people viewing now" box, personalized recommendation blocks and a countdown that relies on server time. Instead, run the countdown in the browser against a fixed end time. Show stock levels through a short lived cache.

Also avoid sending ads to search or filter result pages. Those pages run a different query for every combination. Use a cached campaign page or category page instead. The add to cart step should also rely on a request that is as light as possible.

Forms and tracking tags add load too. For example, one extra server request per page view turns into thousands of extra operations at peak. Keep forms simple, consolidate tracking in a tag manager and check how long each request takes during testing. Then review the mobile version separately, because much of campaign traffic usually comes from phones.

When do a waiting room and rate limiting make sense?

A waiting room holds visitors above your capacity on a lightweight page and lets them in gradually. It works well for ticket drops or limited stock launches, where everyone arrives in the same second. That way, the shoppers already inside can finish checkout, and the site does not collapse.

Rate limiting is a simpler tool. The example in the nginx documentation limits requests from a single address to a set rate:

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
location /search/ {
    limit_req zone=one burst=5;
}

According to the documentation, rejected requests receive a 503 response by default. Apply this to expensive endpoints such as search, not to the whole site. Otherwise, you will block real customers as well.

If you must take part of the site offline for a while, Google Search Central recommends limiting functionality instead of shutting the site down. For short outages, it suggests a 503 status code with a retry-after header and warns against keeping that state for more than a day or two.

How and where should you run a load test?

A load test simulates campaign traffic ahead of time, so you can see where the site chokes. With open source tools such as Apache JMeter, k6 or Locust, you script a real user journey: homepage, campaign page, product, cart.

However, do not hammer your live site without permission. On shared hosting, a heavy test hurts neighboring sites, and your provider may mistake it for an attack and block your IP. Here is the safer approach:

• Build a staging copy with the same settings as production.
• If you must test live, notify your provider in writing and agree on a time window.
• Ramp the load up gradually instead of starting with a sudden peak.
• Record response time, error rate and server resources at the same time.
• Test cached pages and uncached steps such as the cart separately.

The goal is not a headline number. Instead, you want to find the breaking point and see which resource runs out first. For example, if workers fill up, you go back to caching; if the database waits, you go back to queries. Then you fix the issue and run the test again.

When and how should you add hosting capacity?

If the test still shows a shortfall after the software fixes, it is time to scale the hardware. On shared hosting, that usually means a higher plan; on a VPS, it means more CPU and memory. We walk through a smooth switch in how to upgrade your hosting plan without downtime.

We compare VPS, VDS and cloud servers, including capacity planning for campaigns, in VPS vs cloud server vs VDS, so we will not repeat it here. Put simply, cloud servers suit temporary scaling better, while fixed plans offer more predictable costs.

Timing is critical. Upgrade before your load test, not on launch day, so you can measure the new capacity too. Also ask your provider whether you can scale back down after the campaign and whether that step needs downtime. If you need to move servers, lower your DNS TTL well in advance.

Which metrics should you monitor, and how do you set alerts?

Without monitoring, you learn about a website crash from an angry customer message. Before the campaign, track at least these signals:

• Availability: an uptime service that checks the site from several outside locations.
• Response time, especially for the campaign page and the cart.
• Error rate: the share of 5xx responses among all requests.
• Server load: CPU, memory and swap usage.
• Active workers on the PHP-FPM status page.
• Database connections and the count of slow queries.
• Disk usage, because log files grow fast under heavy traffic.

To read load figures correctly, see what load average means on Linux. Base your alert thresholds on your own normal days, not on someone else's numbers. For instance, trigger an alert when response time rises well above its usual level. For a quick outside check during the campaign, use our is it down checker. Finally, write down who receives alerts at night and what that person may decide on their own.

How do you prepare backups and a rollback plan?

Campaign week is not the week for changes. So declare a code and plugin freeze a few days before launch, and push theme, plugin and core updates until after the campaign.

Next, take a full backup and test the restore. A backup you cannot restore is not a backup. For backup types and retention, see our website backup strategy guide. Also make sure backup jobs do not run during the campaign window, because backups put real pressure on disk and CPU.

Your rollback plan needs three things. First, the steps to return to the last working version. Second, switches that turn off heavy features such as recommendations or live search with one setting. Third, a lightweight busy page that returns a 503 status, plus a short status message for social media. That way, you follow a ready plan in a crisis instead of improvising.

How do you align ad budgets and landing pages with the tech team?

When tech prep and the ad plan run separately, you get the most expensive mistake: ad spend keeps flowing per click while the site crawls. That is why the ad team and the tech team should work from the same calendar.

In practice, send your email list in batches rather than all at once. Split push notifications into groups. Raise ad budgets as you watch how the site responds, not at the very first minute. Also tag every channel with UTM parameters, so you can see right away which channel drives the spike.

Decide in advance what happens when the site slows down. Which campaigns will you scale back, which will you pause, and who signs off? Pausing Google Ads or Meta campaigns takes only a few clicks; debating the decision mid crisis wastes time. We handle this coordination as part of campaign planning in our Google Ads management service.

Which tasks should you leave to your hosting provider?

To be honest, you do not have to handle every fix yourself. On shared hosting, you cannot touch PHP-FPM, web server or database settings anyway; those belong to the provider. With such a plan, your part is the site itself: the caching plugin, images, plugins and the campaign page.

On a managed VPS, tune server settings together with your provider. Even if you run your own server, avoid editing config files on the eve of a campaign when your Linux and web server experience is limited. One wrong setting can take the site down before any traffic arrives.

Network level attack protection, data center capacity and hardware failures stay with the provider in every case. Tell them in writing about the campaign date, the expected spike and your load test plan. As a result, you will get faster support if something goes wrong.

So when should you call in a specialist? If the load test shows a breaking point you cannot explain, if the logs show errors you cannot interpret, or if you need a major infrastructure change days before launch, outside help lowers the risk. On the other hand, site speed and landing page work usually sit well within your web team's reach.

Website crash prevention checklist for launch day

On the morning of the campaign, go through these items in order. Share the list with everyone on the team, and give each item an owner.

• Caching is on and shows the sale prices correctly.
• Cart, checkout and account pages stay out of the cache.
• The CDN is live and serves the static files.
• The code and plugin freeze is in effect.
• A fresh backup exists, and the restore steps are at hand.
• Uptime, response time and error rate alerts are active.
• Heavy cron jobs and backups sit outside the campaign window.
• A test order has confirmed the payment and shipping integrations.
• Ad and email send order matches the tech team's plan.
• The busy page and the status message are ready.
• The provider's support channel and the contact list are on hand.

Each item here is the final check of a measure from the sections above. In other words, the checklist does not replace the preparation itself.

What should you do first if the site slows down mid campaign?

No matter how well you prepare, an unexpected slowdown can still happen. Following a sequence you wrote in advance, instead of panicking, keeps a brief slowdown from turning into a full website crash.

1. First, confirm the problem: do the outside check, response time and error rate tell the same story?
2. Next, find the exhausted resource: workers, memory or the database?
3. Switch off heavy but optional features: live search, recommendation blocks, filters.
4. Check that caching is really active and that the campaign page comes from the cache.
5. Scale back ad budgets or hold the remaining email batches.
6. If things do not improve, contact your hosting provider and switch on the busy page if needed.

Log every step with a timestamp. Then, in the post campaign review, you will see clearly what worked.

What should you review after the campaign ends?

Once the campaign is over, hold a short review while memories are fresh. When you put server graphs, error logs and ad data side by side, preparing the next campaign becomes much easier.

Look for answers to these questions. When did peak concurrent traffic arrive, and which channel triggered it? At what point did response time rise, and which resource ran out first? Which alert helped, and which one only made noise? Did ad spend go to waste while the site was slow?

After that, plan to roll back the temporary capacity, lift the code freeze and apply pending updates in a controlled way. As a result, each campaign runs calmer than the last, and the risk of a website crash keeps shrinking.