Prepare the controls you'll need on Black Friday
Peak-traffic preparation needs a tested checkout path. It also needs someone authorized to disable a failing promotion without waiting for a deployment.
Decisions made in August can determine which problems a team can fix during Black Friday 2026.
Deployment restrictions set the available response options in November. Load tests establish what happens when traffic reaches four times its usual level. Both need attention before the campaign begins.
Use the previous peak as a baseline
BFCM 2025 gives teams a starting point for planning. Shopify processed $11.5 billion, about a quarter above the previous year. Black Friday traffic reached roughly 4.2 times a normal day; Cyber Monday reached about 3.5 times.
Across that weekend, Vercel served more than 56.9 billion cached requests. It verified 2.4 billion human interactions while blocking more than 415 million bot attempts. Capacity planning needs to account for unwanted traffic arriving during the customer peak.
Longer promotional windows spread some demand across more days. That can reduce the concentration seen in 2020, though the remaining peaks still need a capacity plan.
Include checkout dependencies in the test
A third-party timeout can block checkout. An untested promotional-code case can also interrupt a purchase, while an admin outage can leave support without the information it needs. Frontend performance testing needs to cover those failure paths.
During Shopify's 2025 admin disruption, merchants briefly lost dashboard access while sales were largely unaffected. The storefront has a different failure path from the tools merchants use to operate it. Each needs a recovery plan.
I've repeatedly seen an overlooked integration cause the outage. Testing needs to follow every dependency required to complete a purchase, even when the team's attention has been on another part of the code.
Prepare the response controls
From early November, restrict dependency updates. Delay refactors that could affect checkout. Keep operational controls available during the freeze. Feature flags may need changing during an incident, as may search or payments configuration. Observability also needs to remain adjustable when the team needs more information.
Give promotional elements a way to be disabled without deployment. A countdown or recommendation widget can fail independently of the storefront. An external analytics script may need the same control. Removing the build requirement shortens one part of the response, although the actual recovery time still needs testing.
Load-test a purchase through its stateful steps. Start with adding an item, then apply the promotional code before checkout. Include the payment callback. A cached homepage can respond normally while those uncached operations queue up.
Run a rollback rehearsal with the person scheduled to be on call. Time the procedure on an ordinary working day. A twenty-minute restore that nobody has run this quarter leaves uncertainty about the response the team can achieve during the peak.
Name the person authorized to disable a promotion. Record the decision in writing, then confirm that someone with that authority will be available during the campaign. Incident time should go into recovery instead of discovering who can approve it.
Spend the remaining testing time deliberately
If time before November is limited, the following checks cover failure paths that a homepage benchmark can miss.
Test checkout end to end with realistic concurrency. Use actual sessions against the payment sandbox, exercising the promotional logic. A Lighthouse run against a warm cache measures a different part of the experience.
Measure each external script on critical pages. Decide whether its work justifies the delay it introduces, then remove or defer scripts that can wait until after the purchase. The resulting budget gives later additions a limit to work within.
Exercise monitoring at four times normal traffic. Check whether the dashboards remain readable under load. Test the alert thresholds too: ordinary-day settings can produce continuous alarms during a peak or miss the signal the team needs.
Set authority before the incident
Technical preparation depends on decisions about permitted changes. Someone needs authority over each response control, with an agreed order for disabling features if service deteriorates. Even after testing the code, the team needs an authorized response ready for an incident.
Write down the first recovery action with its owner before the overnight shift needs to use it.
I work with teams on peak-traffic readiness, using load tests to examine dependencies before an event. That includes deciding which third-party work belongs on the purchase path.