WooCommerce Flash Sale Traffic Spike: A Hosting Checklist
Every store owner remembers the sale that broke their site. The ad campaign goes live, a few hundred people click through in the same ten minutes, and the checkout page starts timing out just as orders were supposed to start rolling in. The good news: almost none of this is bad luck. It's a handful of settings that were never sized for a spike, and you can check every one of them before you hit publish on the sale.
Why Sites That Run Fine Normally Fall Over During a Sale
A store that handles 50 concurrent visitors comfortably can choke at 300, and the reason is almost always the same: your day-to-day traffic never touches the limits that are quietly configured on your server. PHP-FPM worker pools, MySQL's max_connections, your cache's hit ratio, and your payment gateway's webhook queue all have ceilings. Normal traffic stays well under them. A flash sale, an influencer post, or a festive-season campaign pushes past all of them within the same few minutes, and each one fails differently — some as a blank page, some as a 502, some as an order that never confirms.
Fixing this after the sale has started is painful because everything looks broken at once. Fixing it two weeks before costs you an afternoon.
The Two-Week-Out Checklist
1. Turn On Full-Page Caching (and Actually Test the Cache Hit)
If you're not running a page cache — LiteSpeed Cache, WP Rocket, or your host's built-in caching — a spike will hammer PHP and MySQL for every single visitor, even ones just browsing the homepage. Enable it, then confirm it's actually working:
curl -I https://yourstore.com/ | grep -i cacheLook for a header like x-litespeed-cache: hit or x-cache: HIT on the second request. If you only ever see MISS, the cache isn't serving pages and you're getting none of the benefit.
One WooCommerce-specific catch: cart, checkout, and account pages must stay excluded from full-page cache, or customers will see each other's carts. Every major caching plugin excludes these by default — just verify the exclusion list still lists /cart/, /checkout/, and /my-account/ before the sale, not after.
2. Check pm.max_children Against Expected Concurrency
You don't need a deep PHP-FPM tuning session two days before a sale — just a sanity check. SSH in and look at your current pool size:
grep -E "pm.max_children|pm = " /etc/php/*/fpm/pool.d/*.confAs a rough floor: pm.max_children should comfortably exceed the number of concurrent checkout attempts you expect, since checkout and cart pages can't be served from cache. If you're expecting 40 people mid-checkout at once and your pool caps at 10, that's your bottleneck — raise it, or upgrade the VPS plan a tier for sale week and scale back down after.
3. Confirm MySQL's Connection Limit Isn't the Ceiling
mysql -e "SHOW VARIABLES LIKE 'max_connections';"
mysql -e "SHOW STATUS LIKE 'Max_used_connections';"If Max_used_connections from a previous busy day is already sitting close to max_connections, you're one traffic bump away from "Error establishing a database connection" — and that error hits every visitor, not just the ones checking out.
4. Offload Static Assets to a CDN
Product images are usually the heaviest part of any store page. Routing them through Cloudflare, BunnyCDN, or similar means a traffic spike hits edge servers instead of your origin VPS for every image request, leaving your server's capacity for the parts that actually need PHP — cart, checkout, and search.
The Three-Days-Out Checklist
| Check | Why It Matters |
|---|---|
| Payment gateway webhook logs | Razorpay/Stripe webhooks that silently fail leave orders stuck "on hold" even when payment succeeded |
| SSL certificate expiry | An expired cert on sale day turns checkout into a broken-lock warning for every customer |
| Coupon and stock rules | Test the actual discount code and confirm stock quantities are correct — not just that the plugin is active |
| Backup taken | A fresh backup right before the sale, separate from your regular schedule, so a bad plugin update mid-sale is reversible in minutes |
| Disable non-essential cron-heavy plugins | Report generators, log-heavy SEO plugins, and analytics that hook into every page load add up under concurrency |
For the webhook check specifically, look at your gateway's dashboard for failed or retried webhook deliveries in the last week — a webhook endpoint that's timing out under normal load will fail outright under sale-day load, and that's the difference between an order marked "Processing" and one stuck "Pending" with a customer who already paid.
Day-Of: What to Watch in Real Time
- Server load and PHP-FPM queue — run
watch -n 5 uptimein one terminal tab and keep an eye on the PHP-FPM error log in another during the first hour of the sale, when traffic is highest. - Cache hit ratio — if it drops mid-sale, check whether a plugin update or a logged-in-only banner is bypassing cache for anonymous visitors.
- Order completion vs. cart abandonment — a spike in abandoned carts with no matching error in your logs often points to a slow payment gateway response, not your server.
- A rollback plan — know in advance how you'd disable a misbehaving plugin or scale the VPS up without needing to research it while the sale is live.
Prevention: Make This a Repeatable Checklist
The teams that stop dreading sale day are the ones who turn this into a saved runbook instead of re-learning it every time. Keep a copy of your cache exclusion list, your PHP-FPM pool values, and your MySQL connection limits in one document, and re-check them before every major sale — not just the first one. If you're consistently upgrading your VPS plan for a few days around each sale, ask your host whether temporary resource scaling is available instead of paying for peak capacity year-round.
Frequently asked questions
How many concurrent users can a typical VPS handle before checkout slows down?
It depends far more on pm.max_children and your database connection limit than on raw traffic numbers. A modestly sized VPS with a well-tuned PHP-FPM pool and a working page cache can often handle a few hundred concurrent visitors, but only a fraction of those are usually in checkout at once. Test your specific pool size rather than relying on a generic number.
Should I upgrade my VPS plan just for sale day?
If your normal traffic is well below your sale-day estimate, a short-term upgrade is usually cheaper and safer than permanently over-provisioning. Scale up a few days before the sale so caches and services have time to warm up, and scale back down once traffic normalizes.
My cache is working but checkout is still slow. What else could it be?
Checkout pages can't be cached, so check PHP-FPM worker availability, MySQL connection limits, and your payment gateway's response time first. A slow third-party webhook call during checkout will hold a PHP worker open until it times out, which quietly eats into your available pool.
How do I know if my payment gateway webhooks are the problem?
Check your gateway's dashboard for failed, delayed, or retried webhook deliveries. If orders are stuck on 'Pending' or 'On Hold' despite successful payments, it's almost always a webhook that isn't reaching your site in time, not a WooCommerce bug.
Is it worth disabling plugins right before a sale?
Yes, for anything non-essential that runs on every page load — heavy analytics, report generators, and SEO plugins that scan content on the fly. Keep only what checkout and cart actually depend on active during peak hours, and re-enable the rest afterward.