Board Technology Oversight

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.

A laptop on a desk showing a simple dashboard beside a notebook.

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.

Next step

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.

Stop Guessing. Start Scoring
Tyson Martin

Written by Tyson Martin, NACD.DC

Chief Trust, Security & AI Officer. CISO of record at MIO Partners; former CISO & CTO at Lumber Liquidators and Orvis; advisor to 200+ Fortune 500 boards and C-suites at AWS.

See the track record
Keep reading

More on Board Technology Oversight

All CISO Insights
Board Technology Oversight

What Changed Since the Last Technology Update?

A useful technology update helps readers see what changed, what stayed the same and what remains an open question without rereading the whole history.