Black Friday load testing: know your breaking point before the sale

Detailed documentation →

The question on sale day is not "will we stay up?" but "how many times our normal traffic can we take?". Find that number weeks before the sale, while there is still time to fix things. This page covers how to set up the rehearsal, what to watch, and how to start in a few minutes with Spitfire's ready-made template.

Ask the question as a multiple of normal

"400 requests per second" means little; "three times a normal peak hour" means a lot. First find your normal peak: divide the busiest hour's request count in your access logs by 3600. Then climb in multiples of that rate, stage by stage: 1×, 2×, 3×, 5×. Hold each stage for a few minutes so queues and caches settle. Write the criteria first: for example p95 under 800 ms and errors under 2%. The result is one sentence: "held at 3×, not at 5×."

Sale traffic is not just more, it is different: heavy on the sale page, search and product details, with more add-to-cart and checkout. Keep the rehearsal's flow close to that mix. If the sale starts at midnight, the load arrives as a jump, not a ramp; try that separately with a spike test (test types).

A three-week plan

1. Week 1: measure. Run the rehearsal; write down at what multiple of normal it broke and what broke (latency or errors, which step).
2. Week 2: fix. Start with the narrowest bottleneck: the database connection pool, a slow query, a list that is not cached, autoscaling's reaction time.
3. Week 3: run again and plan. Run the same test on the same environment and compare the two runs. A breaking-point run's capacity card estimates, as a range, how many servers the target traffic needs.
4. Sale week: no load tests. The code is frozen; watch the main flow on production at low load and at regular intervals with synthetic monitoring.

Check before the rehearsal

• WAF and rate limits. Allow-list the load generator's address, or what you measure is your firewall's limit, not your system's (a flood of 429s or 403s).
• Outside services. Do not send load to payment, SMS or shipping providers; use mock services in their place.
• Data. Call a realistic spread of products, not a single one; asking for the same record over and over stays in the cache and makes the system look stronger than it is.
• Alerts. Tell the team when the rehearsal runs; if alerts fire, that is a finding too: at which stage would the same alert fire on sale night?

With Spitfire, in four steps

1. Install Spitfire on Docker or Kubernetes with one command (installation guide) and enter the free key.
2. Tests → From a template → Sale-day rehearsal: enter your site's address, the product list and product detail paths and the visits per second at a normal peak hour. The stages are worked out from that number (for 20: 20 → 40 → 60 → 100 visits/s), two minutes each.
3. Run. The run stops as soon as p95 passes 800 ms, errors pass 2%, or the system slows so much that the target rate can't be sent, so it does not push your system longer than it has to.
4. Read the result. The "What we saw" summary and the findings at the top of the run page say why it stopped; the charts show at which stage it broke. The same result comes as an HTML and PDF report too. A real run's report: sample report.

To add cart and checkout steps, open the test in the editor; a ready login, cart and checkout flow is on the examples page. With your systems' OpenTelemetry or Prometheus data connected, the run page also shows which service slowed down at the failing stage.

Frequently asked