A sale-day rush is weather you invited. The email goes out, a few thousand people arrive in the same ten minutes, and a store that handles a normal Tuesday fine goes down exactly when it’s earning the most. The preparation below assumes your site is already behind Cloudflare and that you have a staging copy to test against. Start at least a week out — none of this is day-of work.

Estimate the load you’re inviting

Rough math beats no math. Take your email list size times a 2–5% click rate, add whatever ads and social will send, and assume most of it lands in the first half hour. Divide by 1,800 seconds and you have arrivals per second; multiply by a three-minute average visit for concurrent users. A 20,000-person list can put a few hundred people on the site at once — against a normal peak of maybe twenty. The hosting rule of thumb is to prepare for 8–12× your usual peak. Write your number down; every later step checks against it.

Cache every page that doesn’t have a cart in it

The only visitors your server should personally greet are the ones holding a cart. Home page, landing page, product pages, category pages — all of it should come from Cloudflare’s edge, not PHP. Create a Cache Rule that caches HTML for your public pages (Cloudflare doesn’t cache HTML by default) with an Edge TTL of an hour or more. The sale landing page is the page to be most aggressive about, since it’s where the email points and where the stampede hits first.

Keep cart and checkout out of the cache

This is the half that breaks stores when it’s skipped: a cached cart shows one shopper another shopper’s items. Add a bypass rule above your caching rule covering /cart*, /checkout*, /my-account*, and any URL containing wc-ajax. Then bypass on session cookies too — for WooCommerce that’s woocommerce_items_in_cart, woocommerce_cart_hash, and anything starting wp_woocommerce_session_ — so a shopper who has picked something up gets live pages everywhere. Order matters: Cloudflare applies the last matching rule, so confirm the bypass actually wins on those paths.

Check your host’s and gateway’s ceilings

Your host has a concurrency ceiling, usually expressed as PHP workers — each uncached request occupies one, and a typical plan has five to ten. With caching absorbing browsers, workers only serve carts, but confirm the number against your estimate and ask your host what a temporary bump costs; it’s cheap insurance. Then the ceiling nobody checks: your payment gateway. A sudden burst of charges from a normally quiet account looks like fraud to their models, so tell your gateway the sale dates ahead of time, and skim PCI compliance in plain language if that account review is overdue anyway.

Run a load test on staging

Prove the number instead of hoping. On staging — never live — run k6 (the open-source cachewerk/k6 suite ships WooCommerce scenarios) ramping to your estimated concurrency:

k6 run --vus 200 --duration 5m loadtest.js

Watch response times and error rates as it ramps. Flat and fast means the cache is doing its job; a cliff tells you the real ceiling, and where — usually the uncached cart requests hitting your worker limit.

Write the day-of rollback plan

Decide now, calmly, what you’ll do if it tips over anyway: which plugin turns the sale off, the static “back in ten minutes, discount honored” page ready to publish, your host’s support number, and who’s watching the first hour. A plan you wrote at your desk beats one improvised during the storm — that’s most of what a plan is for.

Test-order under the new caching rules

You changed how checkout pages are served, so prove checkout still works: a full test order in a private window, watching that cart contents follow you between pages and the confirmation arrives. Then verify the caching itself:

curl -sI https://YOUR-STORE.com/ | grep -i cf-cache-status
curl -sI https://YOUR-STORE.com/cart/ | grep -i cf-cache-status

The first should say HIT, the second BYPASS or DYNAMIC. Cached home page, uncached cart, clean test order: you’re ready for the crowd. Send the email.