Peak events do and don't

These guidelines summarize the patterns that distinguish teams that sail through BFCM from teams that spend the night firefighting. Each item maps to a specific failure mode observed in real peak-event incidents.

Planning and modeling

Do	Don’t
Derive VU targets from last year’s actual peak data	Guess a “big” VU number or use average daily traffic
Add 20 % safety headroom above the modeled peak	Test at exactly the projected number — model error will bite you
Break down load by funnel stage (browse/PDP/cart/checkout)	Run all VUs against the payment endpoint in isolation
Document the traffic model so every engineer uses the same numbers	Keep the target VU count in your head
Obtain written authorization before testing against any third-party API	Assume sandbox environments are fair game without reading the ToS
Start the readiness program at T-6 weeks minimum	Start at T-2 weeks and try to compress everything

Test design

Do	Don’t
Use a near-instant ramp (20–30 s) for doorbuster spike scenarios	Use a 5-minute ramp to simulate a flash sale — it undersells the shock
Include a post-spike recovery window (5 min minimum)	End the run immediately after the peak — you miss the recovery data
Use randomized, realistic data from CSV: product IDs, session tokens, search terms	Use the same product ID for every VU — it creates artificial cache hit rates
Label every Taurus request — you need per-endpoint breakdown	Use a single unlabeled scenario that averages all endpoints
Set per-label failure criteria on every critical endpoint	Use only a global error rate criterion
Test the full journey from homepage to order confirmation	Load-test only the payment endpoint — every upstream step is a potential bottleneck
Run a multi-hour soak test before the dress rehearsal	Skip the soak because “we passed the 20-minute load test”

Timing

Do	Don’t
Complete stress and spike tests at T-3 weeks	First-test with a spike at T-1 week
Run the dress rehearsal at T-1 week with time to fix issues	Run the dress rehearsal on the Monday before Black Friday
Gate each phase on passing failure criteria before moving to the next	Keep running the readiness program regardless of test results
Include a go/no-go gate sign-off before the event	Let the event date drive the decision regardless of test outcomes
Schedule soak tests to run overnight and review results in the morning	Watch an 8-hour soak test live

Failure criteria and gating

Do	Don’t
Configure failure criteria before the first readiness run	Add failure criteria after the stress test, when you already know the numbers
Gate each readiness phase on previous phase passing criteria	Move from load → stress → spike regardless of whether load test passed
Use the dress rehearsal result as the year-over-year comparison baseline	Use last year’s production traffic numbers directly as the pass/fail threshold
Make the go/no-go decision with engineering lead AND business lead	Let engineering decide alone — the business has skin in the game
Archive every readiness run with a tag for next year	Lose the run history at the end of the year

Cache and infrastructure

Do	Don’t
Pre-warm CDN caches 2 hours before sale start	Let the first real users prime the cache — the cold miss rate under spike is catastrophic
Coordinate cache warming with the ops team as a formal checklist item	Assume the cache is warm because it was warm yesterday
Confirm autoscaling policies are tested and tuned before game day	Rely on autoscaling that has never been tested under BFCM-shaped load
Verify database connection pool settings under peak load during readiness testing	Leave the default pool settings and hope for the best

Partners and third parties

Do	Don’t
Deploy mock servers for payment, tax, shipping, and fraud in staging	Call real payment processor APIs with synthetic load test traffic
Test your circuit breakers by intentionally disabling mocked dependencies during a load test	Assume circuit breakers work because they passed unit tests
Test the inventory contention scenario (500 VUs on one limited-inventory SKU)	Assume your ORM handles concurrent inventory updates correctly
Verify rate limit handling: your app retries correctly on HTTP 429	Assume the payment processor rate limit is high enough that you will never hit it

Game day

Do	Don’t
Write the war-room runbook before the dress rehearsal, not the night before	Write the runbook under pressure during the event
Assign specific metrics to named engineers — “everyone watches everything” fails	Rely on a general “keep an eye on it” approach
Define abort criteria in writing before the event	Make the abort/rollback decision in real time with revenue numbers in front of you
Run a pre-sale smoke test 60 minutes before go-live	Assume everything is fine because the staging tests passed
Practice the runbook with a deliberate amber injection during the dress rehearsal	Read the runbook for the first time when you actually need it

Post-event

Do	Don’t
Run the year-over-year comparison in MaxoPerf within 48 hours	Forget to compare and lose the data that will anchor next year’s program
Archive the game-day run with a permanent tag	Leave the run untagged in a list of hundreds of runs
Hold a blameless post-mortem within 5 business days	Skip the post-mortem if the event “went well enough”
Set a calendar reminder for T-8 weeks before next year’s BFCM	Rediscover the readiness process in October next year with no record of this year’s program

Where to go next

• BFCM readiness checklist — the complete task-level checklist for the full program.
• Daily countdown calendar — the week-by-week schedule.
• Peak events overview — the full section index and reading order.