Black Friday, Cyber Monday, and festival sales can bring 5-10x normal traffic in a matter of hours — and the cost of getting caught unprepared is brutal. J.Crew lost an estimated $775K in a single Black Friday outage. Costco's site went down for over 16 hours and cost roughly $11M. Even infrastructure providers aren't immune: a 52-minute Fastly outage during Black Friday 2023 knocked thousands of ecommerce sites offline at the worst possible moment. This checklist is for the engineering leads, ops managers, and founders who need to walk into peak season confident their ecommerce infrastructure will hold.

Before you start: set a readiness timeline

  • [ ] Identify your peak dates and expected traffic multiplier (use last year's analytics plus category growth trends)
  • [ ] Set a code freeze window for non-critical deploys — most retailers freeze roughly 6-8 weeks around major sales events, since a bad deploy on the biggest revenue day of the year is the worst time to discover a regression
  • [ ] Assign a single incident commander and an on-call rotation covering the full peak window, including time zones if you sell internationally
  • [ ] Confirm vendor SLAs (payment gateway, CDN, hosting, shipping API) and get direct escalation contacts, not just support tickets

Technical infrastructure

  • [ ] Auto-scaling — verify scaling triggers fire well before saturation, not at 100% CPU; test that scale-down doesn't break warm caches after a burst
  • [ ] CDN and caching — push as much static and semi-static content (product images, category pages, pricing) to the CDN edge as possible; every cached response is free capacity you don't have to provision
  • [ ] Database connection pooling — use PgBouncer, ProxySQL, or your stack's equivalent to prevent connection storms when traffic spikes suddenly
  • [ ] Stateless application layer — confirm sessions don't pin users to a single server, so horizontal scaling actually distributes load
  • [ ] Load testing in three shapes, not one:
    • Spike test: fast ramp to peak, hold, gradual decay (mimics a flash-sale launch)
    • Burst-and-recover test: drop to baseline mid-load and spike again (confirms autoscalers recover cleanly)
    • Sustained peak test: hours at expected peak volume, not just minutes
  • [ ] Graceful degradation plan — decide in advance which features get disabled under extreme load (recommendation widgets, live inventory counts, non-critical personalization) to protect checkout
  • [ ] Rate limiting and queueing — have a virtual waiting room or queue mechanism ready if traffic exceeds even your scaled capacity

Payments and checkout

  • [ ] Map your full payment chain end to end: checkout → gateway → processor → acquiring bank → card network → issuing bank → fraud tool → webhook → order system → inventory → confirmation email. Any single link can fail independently of the others.
  • [ ] Confirm gateway failover — a single-gateway dependency with no backup is one of the most common causes of checkout outages during peak load
  • [ ] Test webhook reliability specifically; a gateway that's technically "up" can still silently stop updating your order system if webhook delivery fails
  • [ ] Re-run your PCI DSS scope check before peak season if you've made any checkout or payment-page changes
  • [ ] Stress-test fraud rules against realistic peak-traffic patterns — unusual transaction velocity during a sale can trigger false declines on legitimate customers if rules aren't tuned

Inventory, fulfillment, and third parties

  • [ ] Confirm real-time inventory sync between storefront, ERP/OMS, and warehouse systems — oversells during peak sales are one of the fastest ways to generate support tickets and chargebacks
  • [ ] Check rate limits on every third-party API you depend on (shipping calculators, tax engines, loyalty platforms) and confirm what happens if you hit them
  • [ ] Have a rollback plan for any recent platform migration or major integration change — don't let peak season be the first real test of a new system under load
  • [ ] Build in a plan B for a critical dependency outage (like a CDN or DNS provider going down) — even providers with strong uptime records have had major incidents during past Black Fridays

Support, fraud, and operations

  • [ ] Staff support and fraud review teams for the full traffic window, not just business hours — thin staffing during peak is actively exploited by fraudsters hiding in legitimate volume spikes
  • [ ] Expect a chargeback increase in the weeks after the sale (buyer's remorse and friendly fraud can push chargebacks up significantly in January) and have review capacity ready, not just during the event itself
  • [ ] Pre-write customer communications for common failure scenarios (delayed shipping, backorder, payment declined) so support isn't improvising under pressure
  • [ ] Set clear escalation paths for "site is degraded" vs. "site is down" so the right people are paged at the right severity

Red flags to watch for in the weeks before launch

  • [ ] Load tests only run at steady throughput, never spike or burst shapes
  • [ ] No documented rollback procedure for the current release
  • [ ] A single payment gateway with no failover configured
  • [ ] Support and fraud teams sized for average-day volume, not peak
  • [ ] No one has actually tested what happens when a third-party API rate-limits you mid-checkout

How to use this checklist

Work through each section with the team that owns it — engineering owns infrastructure and payments, ops owns inventory and fulfillment, support owns staffing — and set a hard readiness review date at least two weeks before your first peak event. Anything unchecked at that point becomes a go/no-go conversation, not a surprise on the day.