Black Friday 2026 Load Testing Checklist: A 30-Day Countdown

Black Friday 2026 is Friday, November 27 and Cyber Monday is November 30, so T-30 is Wednesday, October 28. Use the first week to forecast peak traffic from last year and take a baseline, the second to find your ceiling, the third to fix and re-test, and the last week to freeze, warm caches, and run a game day. Test 1.5x to 2x your forecast peak minute, not your average hour.

This page is the calendar. For the general approach to testing a store, see the ecommerce load testing guide; for checkout-specific scripting, see checkout load testing. Here we focus on what to do on which date, with the math to back the targets.

The countdown at a glance

If you are reading this later than October 28, compress the first two windows into one week. Do not skip the ceiling test; it is the single most useful number you will have on the day.

Week 1: forecast peak traffic from last year

Every target in this plan comes from one number: the peak minute you expect on Black Friday. Build it from last year's data, not from average daily sessions.

Step 1: find last year's peak minute at the origin

Pull last year's Black Friday and Cyber Monday from your load balancer or CDN logs at 1-minute resolution. You want origin requests per second (what got past the CDN), because that is what your servers have to handle. Hourly analytics hide spikes: an email drop at 09:00 can produce a minute that is 3–4x the hourly average.

Step 2: apply growth and marketing changes

Worked example (illustrative numbers):

Last year's peak origin minute:       620 RPS   (BF 2025, 09:01 UTC, after email)
Year-over-year growth (Oct vs Oct):   x 1.25    (sessions, comparable non-sale weeks)
Bigger email list / new channels:     x 1.15    (marketing's estimate)
-------------------------------------------------
Forecast peak:                        620 x 1.25 x 1.15 = 891 RPS

Test targets:
  Sustained (1.5x forecast):          ~1,340 RPS for 30-60 min
  Spike (2x forecast):                ~1,780 RPS, ramp in 60 s

Do the same for orders, because checkout is where the expensive work happens:

Last year's peak orders/minute:       95
Forecast:                             95 x 1.25 x 1.15 = 137 orders/min
Test at 2x:                           274 orders/min = 4.6 orders/s
If one order = 7 origin requests (cart, shipping, tax, payment intent,
place order, confirmation, order status poll):
                                      4.6 x 7 = ~32 checkout RPS

That last figure is small next to the 1,780 RPS total, but checkout requests are the ones that hold database locks, call third parties, and lose money when they fail. Give them their own thresholds. If converting between users and RPS trips you up, the RPS calculator and concurrent users calculator do the arithmetic.

Step 3: baseline run

Run the realistic mix at today's normal peak (not the forecast) and save it. This is your reference for every later comparison: if p95 at normal load is already 900 ms, a fix that shaves 50 ms at 2x load matters less than the baseline problem.

What to test, flow by flow

A Black Friday mix is more browse-heavy and more search-heavy than a normal day, with a sharp checkout wave right after promotions go live. A reasonable starting mix (adjust from your own analytics):

Payment provider and other third parties

Do not point a load test at your payment provider's sandbox. Sandboxes typically have lower rate limits than live mode, and some providers' terms prohibit load testing them. Replace the payment call with a stub at your service boundary that returns a realistic latency distribution (for example 300–800 ms with occasional 2 s outliers) and run the real sandbox with a few transactions only. Apply the same thinking to tax, shipping-rate, fraud, and search SaaS APIs: find their documented quotas and check that your peak call rate fits under them.

Third-party scripts in the browser

Protocol-level load tests do not execute JavaScript, so tag managers, review widgets, chat, and personalization scripts are invisible to them. They still hurt on the day: a slow third-party script blocks rendering for real users even when your origin is healthy. Audit them separately with a browser tool, set timeouts, and decide in advance which ones you will switch off from the tag manager if they degrade.

Week 2: find the ceiling

Run a step test: hold each level for 5 minutes, increasing by about 20% of the target per step, until thresholds break or errors appear. Then run a spike from normal load to 2x forecast in 60 seconds; see the spike testing guide for shapes. Record for each run:

• The RPS at which p95 starts to bend upward (the knee).
• The RPS at which errors exceed your threshold, and which error (502, 504, connection resets, application 500s).
• The first resource to saturate: database CPU or connections, app worker pool, cache hit ratio dropping, a third-party quota.

Use an arrival-rate (fixed RPS) model for these runs. A closed VU model slows down when your site slows down, which hides exactly the queueing you are trying to find. In LoadTester, RPS mode with a p95 threshold and auto-stop lets you push to the ceiling without leaving a broken test running against the store. If you have not read load test graphs under pressure before, how to read load test results walks through the patterns.

Week 3: fix and re-test

Fix in order of cheapest per unit of headroom. Typical high-value, low-risk changes this close to the date:

• Cache rules: cache PLP and PDP HTML at the edge for 30–120 s with stale-while-revalidate; normalize or strip tracking query strings (utm_*, gclid, fbclid) from the cache key so email traffic does not bypass the cache.
• Pool sizes: match app worker counts to database connection limits instead of raising both blindly.
• Autoscaling minimums: autoscalers react in minutes; a spike lasts seconds. Plan to raise minimum instance counts for the weekend rather than relying on scale-out.
• Kill switches: feature flags to turn off recommendations, recently viewed, live stock counters and other non-essential calls.
• Waiting room: if the ceiling is below forecast and cannot be fixed in time, a queue in front of checkout is a legitimate plan.

Re-run the same test after each change and compare against the baseline, not against your memory of the last run. The exit criterion is the target load passing thresholds twice in a row; a single pass can be luck with cache state.

T-9 to T-7: verification, game day, freeze

Wed Nov 18: full-scale verification run against production (announced, low-traffic window) to exercise the real CDN, WAF and DNS. Allowlist your load generator IPs in the WAF first, or the test measures your bot protection instead of your store.

Thu Nov 19, game day: run the spike profile while the on-call team practices the runbook. Deliberately trip at least one kill switch and do one rollback. Time how long each takes. If rolling back takes 25 minutes, that is your real recovery time on Friday.

Fri Nov 20, freeze: code and infrastructure freeze until Tuesday, December 1. Only pre-approved emergency fixes. Configuration changes (cache TTLs, flags, scaling) go through the same approval as code.

T-6 to T-1: pre-scale and warm the caches

A cold CDN in front of a promotion launch sends the first minute of traffic straight to origin. Avoid that:

1. Publish sale content early. Put Black Friday pages and prices live behind a date-aware component or flag rather than a deploy at midnight, so the HTML and assets are already cached.
2. Do not purge the whole CDN on launch. Purge specific URLs or tags. A global purge at 00:00 is a self-inflicted cache miss storm.
3. Warm from the sitemap. Request the top PLP and PDP URLs (from last year's top-1,000 list) shortly before launch. Remember each CDN point of presence has its own cache; an origin shield or tiered cache makes warming far more effective.
4. Check the cache key. Request a sale URL twice with a campaign query string and confirm the second response is a hit (cf-cache-status: HIT, x-cache: Hit from cloudfront, or your CDN's equivalent).
5. Raise minimums. Set autoscaling floors to the instance count that passed the sustained test, and pre-warm load balancers if your provider requires a request for that.

The rollback plan

Write it down before the freeze, with an owner per line:

Day of: Fri Nov 27 to Mon Nov 30

• One dashboard everyone shares: origin RPS, p95 and p99 by flow, error rate by status code, orders per minute, CDN hit ratio, database connections and CPU. See p95 vs p99 for why both belong there.
• Watch orders per minute against the forecast. A drop in orders while traffic holds is the earliest sign of a checkout problem, often before error alerts fire.
• Keep a written timeline: promotion launches, spikes, incidents, flag changes. It turns into next year's forecast.
• Cyber Monday is its own event. Re-check scaling minimums and cache state on Sunday evening; do not assume Friday's configuration is still in place.