Black Friday 2026 lands on 27 November. That is eleven weeks from today, and most sites that fail that morning failed weeks earlier, when nobody rehearsed the traffic.
What follows is a twelve-week countdown, so you are already a week behind. That is fine. The order matters more than the calendar: targets before testing, testing before fixing, fixing before freezing, and no unproven code into the day.
What "Black Friday ready" actually means
A website is ready when it can serve the peak number of simultaneous shoppers you expect, at speeds they will tolerate, through the journeys that take their money. Readiness is two numbers you can defend: the concurrent load you have proven, and the response times you held while proving it.
It is not a green Lighthouse score from a quiet Tuesday. That measures one person on an idle server, which is the opposite of the condition you are worried about.
The stakes are worth the effort. Adobe measured 11.8 billion dollars of US online spend on Black Friday 2025, and Splunk and Oxford Economics put the average cost of unplanned downtime at 15,000 dollars a minute across large companies. Black Friday minutes are worth considerably more than average minutes.
What you need before week 12
Four things, none of them a purchase:
- Last year's analytics, or an honest substitute. The whole plan sizes from your own peak hour.
- An environment you are allowed to break. Production in a quiet window with an agreed abort rule, or a staging environment that genuinely resembles production. A staging box with half the servers and a tenth of the catalogue proves half a ceiling at best.
- A load testing tool that can walk a journey: browse, search, cart, checkout, rather than only hammering URLs.
- A named owner. Not a committee. One person who tracks the countdown, chases the fixes, and has the authority to call the freeze.
Agree one more thing up front: what "acceptable" means. A number nobody wrote down cannot fail, which is exactly why targets get skipped.
Weeks 12 to 10: turn last year's traffic into this year's target
This part is arithmetic, not engineering. Open your analytics, find the busiest hour of last year's Cyber Week, and write down sessions in that hour, average session duration, and orders in that hour.
Concurrent users, the number that actually loads your servers:
concurrent users = (sessions per hour x average session minutes) / 60
If your peak hour saw 12,000 sessions averaging five minutes, you were carrying about 1,000 concurrent shoppers. That is your baseline, not your target. Add 20 to 50 percent headroom for growth and heavier promotions, with the higher end if your discounts or ad spend are up.
| Number to write down | Where it comes from | Example |
|---|---|---|
| Peak concurrent users | Peak-hour sessions x duration (min) / 60 | 1,000 |
| Test target | Peak concurrent + 20-50% headroom | 1,300-1,500 |
| Acceptable speed | Response times you will defend at peak | Product page under 2s, checkout steps under 3s |
| Revenue per peak minute | Peak-hour revenue / 60 | Your number, on the wall |
That last row is the one that gets budget approved. When a fix costs a week of engineering time, compare it to what a down minute costs you.
No trading history yet? Size from reach: list size times open rate times click-through, plus expected ad clicks, in the first hour. It will be rough, which is fine, because the next step is to find the real ceiling by test rather than by faith.
Weeks 10 to 8: find your ceiling
Run a real load test: simulated shoppers moving through the same journeys as real ones, ramped to your target and then past it until something bends. Going early is the entire point. Whatever this test finds, you still have time to fix it. The same discovery in November is just bad news.
Two rules make the first test honest.
Test journeys, not pages. A homepage test mostly measures your CDN. The cacheable pages are served at the edge while cart and checkout hit your origin uncached, which is why "the homepage held up fine" and "checkout fell over" are compatible statements about the same day.
Test at human pace. Keep think time in the scenario, the natural pauses while somebody reads a page or types a card number, so the request pattern resembles real traffic rather than a benchmark.
Ramp toward the target over ten minutes or more, hold the plateau long enough to trust the reading, then keep climbing until you find the edge. A practical stopping rule: you have found the ceiling when the slow tail of response times bends sharply upward, or errors pass one percent of requests, whichever comes first.
Read the result as a curve, not a verdict. Response times stay flat, then bend, then break. The bend is your ceiling. If it sits below the target you wrote down in week 12, the gap is your work list.
Weeks 8 to 6: fix in revenue order, then prove it
Fix the paths that take money first: checkout, cart, login, stock checks. Content pages can be slow without costing a sale, and they are the ones your cache already protects.
The usual suspects, roughly in the order they surface:
- Database queries that were fine at ten users and quadratic at a thousand
- Undersized connection pools
- Site search hammering the database
- Third-party calls for payment, tax and shipping rates that slow down exactly when everyone else is also having their busiest day
Give mobile its share of attention. Adobe measured 57.5 percent of Cyber Monday 2025 online sales on mobile. A checkout that degrades under load degrades hardest for the majority of your buyers.
Then re-test with the same scenario and the same targets. A fix is proven when the curve moves, not when the ticket closes. Two or three of these cycles is normal, which is why they need to live in September and October.
Weeks 6 to 4: rehearse the opening minutes
An average-load test proves capacity. Black Friday also opens with a stampede: the email lands, the doors open, traffic multiplies within minutes. That is a spike test, and it deserves its own rehearsal, because a system that holds a steady 1,500 shoppers can still fail when 1,500 arrive in ninety seconds. Autoscaling in particular needs minutes you may not have.
If the rehearsal shows demand beyond any capacity you can build in time, decide now about a waiting room. The honest way to set its admission rate is the ceiling you just measured, not a guess.
This is also when the operational side becomes real. Put dashboards on the numbers you tested against and keep the set small enough to watch: response time on the checkout path, error rate, orders per minute. Route alerts to named people rather than a channel nobody owns at 7am. Then write a one-page runbook: who watches, who decides, and what gets switched off first if the site labours.
Weeks 4 to 2: freeze, then verify the freeze
A code freeze is the recognition that every deploy after your last load test ships unproven capacity. The feature merged in mid-November has never met 1,500 concurrent shoppers, whatever its unit tests say.
Freezing two to four weeks out leaves room for an exceptions process, because real fixes will still be needed. The bar for an exception is simple: is this change worth re-testing, and if it is not worth re-testing, is it worth the risk? Then run one final verification test on the frozen build, so the last result you hold describes exactly the code that will face the day.
The final week, and the day itself
Standby, not construction. Walk the runbook once with everyone named in it. Pre-scale the night before rather than trusting reflexes to be faster than a stampede. Check the site at opening time from a real shopper's position: phone, normal network, full journey.
Then watch three numbers: response time on checkout, error rate, orders per minute. The first symptom of trouble is rarely a crash. It is usually the checkout's slow tail creeping up while the cached pages stay innocently fast.
If the numbers drift, act in the order you wrote down. Shed non-essential load first, recommendation widgets, chat, heavy analytics, background jobs, and protect checkout to the end. A slightly slower site that keeps selling is a good day. Most Black Friday disasters are not the first slowdown, they are the improvised response to it.
And keep the graphs. The day itself is next year's sizing data, honest in a way no forecast can be.
How do you know you are ready?
You are ready when every line is true and you can point at the evidence:
- A load test at target plus headroom, on realistic journeys, passed within the last month
- The spike shape rehearsed, and the opening minutes survived at sale-open rate
- The bottleneck list empty, or each remaining item consciously accepted by someone entitled to accept it
- The freeze active, with the final verification test run on the frozen build itself
- Dashboards live on the tested numbers, alerts routed to named people
- A one-page runbook that names people, not roles, and lists what gets shed first
When it goes wrong, it usually goes wrong like this
Most of these are not infrastructure failures. They are measurement failures, a test that looked reassuring because it quietly measured the wrong thing.
| Symptom | Likely cause | Fix |
|---|---|---|
| Test passes easily, day still hurts | Tested the homepage, not the journeys; cache took the load | Re-test browse-to-checkout; treat cached and uncached ceilings as different numbers |
| Response times awful from the first minute | Test traffic blocked or rate-limited by WAF or bot protection | Allow the test source before the run; verify with a small smoke test |
| Checkout collapses while everything else holds | Uncacheable path saturating the database or third-party calls | Fix in revenue order: pools, queries, payment and shipping timeouts, then re-test |
| Great steady-state result, opening minutes fail | Spike shape never rehearsed; autoscaling too slow | Run a spike-shaped test, pre-scale for the opening, consider a queue with a measured cap |
| November deploy breaks what October proved | No freeze, or exceptions skipped re-testing | Freeze by week 2; every exception earns a verification run |
Eleven weeks compresses honestly. What cannot compress is the order.
I build Evaluat, a load testing tool that runs every virtual user in a real browser, so this is the problem I stare at all year. The plan above works with whatever tool you already have.
If you are further into the countdown than you would like, say where you are in the comments and I will tell you what I would cut.
Originally published at evaluat.com.
Top comments (0)