Will the Website Hold? The Holiday Capacity Question
The holiday traffic spike is the most predictable load test of the year. A few questions now beat a slow checkout on the weekend that matters most.

This weekend is, for many businesses, the highest-traffic stretch of the year. It is also the most predictable load test in their calendar: the date has been known all year, and the cost of failing it is measured in the week's revenue and the customers who do not come back.
The capacity question is not a technical one for the board or the executive team. It is a short list of plain-English questions, asked early enough that the answers can still change something.
Key takeaways
The holiday traffic spike is the most predictable load test of the year.
Capacity is a business question: what does a slow or down weekend cost, and who owns the answer?
Ask what was tested, at what load, and what the fallback is if the answer was wrong.
Know who you call when the site slows, and what they can actually do about it.
Whatever this weekend teaches, write it down for next year's plan.
Step 1: Ask what the peak looks like and how you know
Start with last year's numbers: peak concurrent visitors, order volume per hour, the slowest moments and whether anyone noticed at the time. Then this year's expectation: bigger campaign, new product, more email going out?
The gap between last year's peak and this year's plan is the real question. Everything else is detail.
Step 2: Ask what breaks first and what it costs
Every system has a weakest point under load: the checkout, the search, the payment step, the hosting plan's ceiling. Someone technical knows which one it is. The business question is what an hour of that failure costs in revenue and in customers who quietly leave.
That number is what justifies whatever the preparation costs. Without it, capacity work loses every budget argument to something more visible.
Step 3: Ask what the fallback is
If the site slows on the big weekend, what happens: a waiting page, a phone fallback for orders, a status update for customers? A fallback planned in November is a service decision. The same fallback improvised mid-outage is damage control.
The first 24 hours after a critical supplier goes quiet covers the broader version of this thinking, and setting the restoration order is the judgment framework for the degraded weekend itself.
Step 4: Know who you call and what they can do
During the spike, someone named is watching, and someone named can act: scale the hosting, throttle a feature, post the status note. If the honest answer is that the hosting company gets an email and hopes, the fallback plan is a wish.
Confirm the contact path before the weekend, including whether your provider's support runs holiday hours too.
This fictional example shows the four answers written down. It is an illustration, not a prescription.
| Question | Weak answer | Strong answer |
|---|---|---|
| What peak is expected? | Busy, probably | Last year's peak plus the campaign lift |
| What breaks first? | The site gets slow | A named component and its hourly cost |
| What is the fallback? | We call the host | Waiting page, phone orders, status note |
| Who can act? | Someone in IT | A named person with the provider's holiday line |
Step 5: Write down what the weekend teaches
After the peak, an hour of notes: where it strained, what the numbers hit, what the fallback would have done. Next year's capacity plan starts from evidence instead of anxiety, and the budget argument writes itself.
Frequently asked questions
We are too small for load testing. Does this still apply?
The questions scale down fine. A small shop on hosted e-commerce mostly needs to know the plan's ceiling, the provider's support path and the fallback. That is a phone call and a page of notes, not a testing program.
What if the site is mostly brochure, not transactions?
The cost calculation changes but the questions do not. A down brochure site during the season's biggest weekend still costs the inquiries that never arrive.
Who should own capacity preparation?
Whoever owns the revenue the site produces, working with whoever runs the technology. Capacity fails as a business problem when it is treated as a purely technical one.
Is it too late to act if the peak is days away?
Too late for infrastructure work, in time for the fallback: the status page, the phone path, the named watcher and the provider's support route. Those move the outcome more than most people expect.
A Defensible Next Step
Ask the four questions this week: the expected peak, the weakest point, the fallback, the person who can act. If any answer is silence, that is the work. Book a Decision-Clarity Call if you want a second set of eyes before the spike.
Get Board-Ready on AI and Cyber Risk
A 30-minute call. No charge. You'll leave with a clear read on where your oversight stands and what to do about it.


