A hosting checklist for a WooCommerce Black Friday
By Abdalla Kamesh · Published September 28, 2026 · 4 min read
Disclosure: this post contains affiliate links to Cloudways. If you start a plan through one, StoreToNative may earn a commission at no extra cost to you. The checklist works on any host; Cloudways features named are from their own pages.
Stores do not fall over on Black Friday because they ran out of bandwidth. They fall over because too many people tried to do something dynamic at the same moment — add to cart, check out, log in — and there were not enough PHP workers to serve them.
If you have a mobile app and you are sending a push campaign, you have made that concentration worse on purpose. A push to 5,000 people produces a burst of app opens within a couple of minutes, and each app open is several API requests. That is a sharper spike than any email has ever produced.
Here is the checklist, working backwards from the day.
Three weeks out
1. Establish a baseline. You cannot detect a regression without a before. Time your API and your checkout page from outside your network:
curl -o /dev/null -s -w "%{time_total}\n" \
"https://yourstore.com/wp-json/wc/v3/products?per_page=20&consumer_key=…&consumer_secret=…"Five runs, median. Do the same for your cart page. Write the numbers down.
2. Turn on a persistent object cache if you have not. This is the biggest single improvement available and it specifically helps the uncacheable traffic a spike is made of. Cloudways ships Redis and Memcached built in and includes Object Cache Pro on its plans. The full case.
3. Move to a current PHP version. Test on staging, then switch. Cloudways lets you select per application across 7.4 through 8.4.
4. Verify page-cache exclusions. Cart, checkout, my-account and /wp-json/ must never be page-cached. A cached cart on a busy day is a customer seeing someone else’s basket, and that is a worse day than being slow.
5. Audit your plugins. On staging, find the two or three that add the most time per product query. Deactivate anything you are not using. A promotion is a bad time to be carrying dead weight.
Two weeks out
6. Decide your headroom and resize. On managed cloud, scaling up is a slider. Doubling your server for the last week of November and scaling back in December is cheap insurance — a month of a bigger plan against a day of downtime is not a close call.
7. Freeze changes. No plugin updates, no theme changes, no WooCommerce major versions from here until December. If something must change, it goes through staging first, without exception.
8. Prepare the app side over the air. Build your campaign banner and sale section in the console now, switched off or scheduled with a start and end time. Console changes reach installed apps as soon as they are saved, so anything you are not ready to show should stay switched off. Because these ship over the air, there is no build and no store review in your critical path — which is the entire reason to plan campaigns this way. The full campaign calendar.
9. Test a real order. On a phone, with a real card, through your actual gateway. Then test a refund.
One week out
10. Check your backups, and restore one. A backup you have never restored is a hope, not a plan. Cloudways includes automated backups; the restore is the part to rehearse.
11. Confirm webhooks are Active. WooCommerce → Settings → Advanced → Webhooks. Stale catalog data during a sale is the worst possible time for it. Why sync breaks.
12. Re-run your baseline. Compare to three weeks ago. If it got slower, find out why now.
13. Lower your DNS TTL if you might need to move anything.
14. Write the incident plan. One page: who to call at your host, how to put the store in a graceful degraded state, and who decides. Ten minutes now, worth hours later.
The day before
15. Publish the app configuration. Theme, banner, sale collection promoted. Publish it today, not tomorrow — an app already on someone’s phone fetches the change in the background and shows it on the next open after that, so today’s publish is tomorrow’s design.
16. Set the sale prices, then wait. Flip prices before you announce them, and leave a few minutes for the catalog to propagate to the app before any notification goes out.
17. Verify on a real device. Open the app twice. Tap the banner and confirm it lands on the sale collection. Check a variable product’s sale price in the app, not just in wp-admin.
18. Send the teaser push in the evening, local time to your customers.
On the day
19. Stagger your push sends. This is the most useful operational tip on this list. Do not send to 5,000 people at once — send in batches over fifteen or twenty minutes. Same total traffic, a third of the peak concurrency, and nobody notices the difference except your server.
20. Watch the right things. Server CPU and RAM, PHP worker saturation, checkout completion rate, and your API response time. Not your visitor count — visitor count tells you nothing about whether you are coping.
21. Have one lever ready. Know in advance what you will turn off if you have to: a heavy plugin, live search, related products. Decide now, while you are calm.
22. Do not deploy anything. Whatever it is, it can wait until Tuesday.
The week after
23. Scale back down if you scaled up. 24. Re-run the baseline and record it for next year. 25. Write down what broke, while you remember. Next year’s checklist is this year’s incident notes.
Related reading