A sales peak concentrates a month of orders into a few days, and every weakness in a shop shows up at once. The work that makes it go well happens weeks before, because almost nothing useful can be changed on the day.
Start with the checkout, not the catalogue
Cart, checkout and account pages cannot be cached: caching them can serve one customer's session to another. So they always reach the application, and they are the pages under load when it matters.
Your shop's real capacity is how many people can check out simultaneously, not how many can browse. Test that path specifically at a quiet time and find the number.
Everything else on this list is easier than discovering that number during the peak. Handling a traffic spike goes into what actually runs out first.
Freeze changes two weeks out
No plugin updates, no theme changes, no new features, in the fortnight before.
Not because updates are bad, because a problem appearing during the peak is then unambiguous. A shop that changed nothing and broke has a capacity problem; one that updated three plugins has an unknown.
Apply security updates if something serious appears, and nothing else. Then resume normally afterwards.
Test a real order, end to end
Not a test-mode order. A real one, with a real card, refunded afterwards.
That is the only way to confirm the gateway takes money, the order is recorded, stock decrements, the confirmation email arrives, and any download link works.
Do it for each payment method you offer. A method that has not been used in six months is the one that quietly stopped working. Configuring payment gateways goes into the callback that fails silently.
Confirm the emails actually arrive
Order confirmations are the shop's promise that something happened. When they fail, customers assume the order did not go through and either order again or ask for a refund.
Send test orders to addresses at two or three major providers and check they arrive in the inbox rather than spam. Then check the sending limits on your account. A peak means many more emails per hour than usual, and a hosting account that queues or blocks at a threshold produces a backlog exactly when the mail matters. Fixing WordPress email goes into sending through a service instead.
Get the stock numbers right first
Overselling during a peak is worse than at any other time, because you cannot fulfil and every affected customer is a refund plus a complaint.
Count the shelf against what the shop says, before the peak rather than during. Then check that stock is tracked per variation rather than at product level: parent-level tracking means the shop knows you have twelve without knowing which sizes. Inventory and stock management goes over the settings.
Decide the backorder behaviour deliberately. Selling something you do not have is a decision, and it should be one you made instead of a default.
Reduce pending orders holding stock
An order at pending payment reserves stock. During a peak, abandoned checkouts accumulate and can block real customers from buying items you have.
Shorten the window before pending orders cancel automatically: an hour is usually enough for a slow bank redirect and short enough to release stock quickly.
Simplify the checkout before, not during
Every field is friction, and friction costs most when traffic is highest.
Remove fields you do not use. Allow guest checkout. Show the total including shipping before the final step, unexpected cost at the end is the most commonly stated reason people abandon. See checkout optimization.
Then complete a purchase on a real phone on mobile data, not on a desktop. That is how most of your customers will arrive.
Back up immediately before
And confirm you can reach the backup from somewhere other than the shop.
During a peak, a restore is the last resort and the window for it is minutes. Knowing where the backup is and that it works is what makes that decision possible at all. There is more on verifying one in backing up and restoring.
Decide who watches, and what they watch
Someone should be looking during the peak, and it helps to know what at.
Order flow: orders arriving at a steady rate, then stopping, means something broke rather than that interest ended. Site response time. The error log. And the gateway's own dashboard, so a payment taken without an order recorded is caught in the first hour instead of the first week.
Have a phone alert instead of an email one. Uptime monitoring walks through making it reach a person.
Write down what you will do if it breaks
Three decisions, made calmly in advance.
At what point do you put the shop into maintenance mode rather than take orders you cannot process? Who can authorise that? And what is the message customers see, written now, not composed under pressure. For returning the right status code, see setting up a maintenance page.
Afterwards
Reconcile orders against the gateway for the peak days specifically. A mismatch is a payment taken with no order, and finding it in week one means refunding a handful rather than dozens.
Then count the stock again, note what the actual capacity limit turned out to be, and write both down. Next year's preparation is this year's notes.
Find out what the store can actually take
Planning for a peak without knowing the current ceiling is guesswork, and the number is measurable in advance.
ab -n 200 -c 10 https://example.com/ 2>/dev/null | grep -E 'Requests per second|Time per request|Failed'
for i in $(seq 1 15); do curl -s -o /dev/null -w '%{time_starttransfer}\n' "https://example.com/shop/?p=$i"; done | sort -n | tail -3
Test the pages that cannot be cached rather than the home page, since those are what a peak actually consumes: the basket, the checkout, and any filtered listing.
Run it against a staging copy if the load would be noticeable, and run it at a quiet hour otherwise. The figure you want is the point at which response times rise sharply rather than the maximum the machine will accept, because that knee is where customers start abandoning.
Watch the numbers that predict the failure
During the peak itself there is no time to investigate, so decide beforehand which three readings you will look at.
watch -n 30 'uptime; mysql -e "SHOW STATUS LIKE \"Threads_connected\""; ss -tn state established | wc -l'
Database connections is the one that matters most on a store, because the limit is reached before processor or memory and the symptom is an immediate site wide failure rather than a slowdown.
Have the connection limit and the current count written down in advance. Knowing you are at sixty of a hundred and fifty is actionable; discovering the limit exists during the incident is not. Managing databases on a VPS deals with raising it safely.
Decide in advance what you will switch off
Under load, removing work is faster than adding capacity, and the decisions are much better made while calm.
Write a short list before the day: which features can be disabled without stopping orders, in what order, and who is allowed to do it.
The usual candidates are live search suggestions, related product blocks, on the fly image generation, review widgets pulling from elsewhere, and any report or export that runs on a schedule. None of them is the reason anyone visited, and each is measurable work per request.
Test that each can actually be turned off before the day, since a switch nobody has used is a switch that may not work.