Load Testing for Black Friday: Spike, Soak and Stress
Four load tests worth running before Black Friday: baseline, spike, soak & stress. What each one finds, how to build realistic tests & what to watch.
Published November 10, 2026 by Danish Rumane
6 Minutes to Read
A load test is the only honest answer to "will it hold on Black Friday?" Everything else is a guess. But "run a load test" covers several different tests, and each one finds a different kind of failure. Running only one of them leaves the others to be discovered by customers.
This guide covers the four tests worth running before peak traffic, how to make them realistic, and what to measure while they run. You will need good monitoring in place first, because a load test without metrics only tells you that something broke, not what. If you are still on a single server, our piece on how cloud fixes VPS scaling problems covers the step before this one.
The four tests and what each finds
Baseline load test. Run your expected peak traffic, steadily, for 30 to 60 minutes. This answers the basic question: can you handle the traffic you are planning for, with response times you would accept?
Spike test. Jump from normal traffic to peak in a minute or two, the way it happens when a marketing email lands. This finds what breaks under sudden change: connection pools that cannot open connections fast enough, caches that are empty, and autoscaling that reacts too late.
Soak test. Run moderate-to-high traffic for several hours. This finds slow failures that short tests never reach: memory leaks, connections that are opened and never closed, logs filling a disk, and queues that grow a little faster than they drain.
Stress test. Keep increasing traffic past your target until something breaks. This tells you where the ceiling is and, just as important, how the system fails. A site that slows down gracefully is very different from one that falls over and takes the database with it.
Start at the expected peak to establish a baseline. Then change how quickly traffic arrives, how long it stays or how high it climbs.
Building tests that resemble real customers
A test that hits your homepage 10,000 times a minute tells you very little. Real customers browse, search, add to cart and check out, in proportions you can read from last year's analytics.
Script real journeys. Build a few user journeys, such as browse only, search and add to cart, and full checkout, and mix them in the proportions you saw last peak.
Add think time. Real people pause between pages. Without pauses, each virtual user generates far more load than a real one, and your numbers become meaningless.
Use realistic data. Test against a database the size of production, with realistic product counts and order history. An empty database is always fast.
Run against a copy of production. A copy of production built from recent snapshots gives you a realistic target without risking real customers.
Keep third parties out of it. Point payment, tax and shipping calls at sandbox environments or mocks. Load testing a payment provider's production system without permission is a fast way to get blocked.
Tell your host. A large test can look like an attack. Let your hosting provider and CDN know when you are testing and from where.
Open-source tools such as k6, JMeter, Locust and Gatling can all script journeys like these. The tool matters much less than the realism of the script.
If you would rather run these with engineers who know your environment, test planning and review are part of the managed services included on every InMotion Cloud plan.
What to measure while the tests run
Watch four things across every layer, from the load balancer to the database.
Response time at the 95th and 99th percentile. Averages hide the slow requests your customers actually feel.
Error rate. Any rise in 5xx errors, timeouts or failed checkouts.
Throughput. Requests and orders completed per second. If load keeps rising and throughput stops rising, you have found a ceiling.
Saturation. CPU, memory, disk and network on each server, plus database connections, connection pool queues and queue depth.
At the dashed line, more users stop producing more orders. The rise in p95 response time shows that the slowest requests are taking longer.
The soak test deserves its own slot
Teams skip the soak test because it takes hours. It is also the test most likely to find the failures that hit on day two of a long weekend.
During a soak, watch for:
- Memory that only goes up on application servers
- Database connections that climb and never fall
- Disk usage growing from logs, temporary files or session files. Our guide to disk capacity planning covers how much headroom to keep
- Queues growing a little faster than workers can clear them
Run it overnight. Check the graphs in the morning.
After the tests: fix one thing, test again
Every test should end with one clear bottleneck. Fix that, and run the test again. A different component will become the bottleneck next, and that is progress. The usual order is uncached pages, then database connections and slow queries, then checkout integrations, then server capacity. Our guide to instance performance covers the server side.
Stop when the breaking point sits well above your expected peak and the soak test runs clean. Then record the results, because next year you will want to compare.
Repeat the same customer journey after each fix. Stop when the site has room above the expected peak and stays healthy through the soak test.
Where InMotion Cloud fits
On InMotion Cloud, you can build a test environment from snapshots of your production servers and run tests against it without touching real customers. Because pricing is fixed, test traffic inside your environment does not add to your bill. Our engineers can help plan tests, read the results and make the fixes before your freeze.
What stays with you: writing the test journeys, deciding what response times are acceptable and choosing which fixes to ship.
Summary
Run four tests, not one. A baseline test checks you can handle the plan, a spike test checks you survive the jump, a soak test finds slow leaks and a stress test shows where and how things break. Script real journeys with realistic data, keep third parties in sandbox, measure percentiles and saturation, and fix one bottleneck at a time.
Not sure your load test reflects real peak-day traffic?
InMotion Cloud engineers will help you plan the tests and read the results before your freeze.
Frequently asked questions
What is the difference between a load test and a stress test? A load test runs your expected traffic to check you can handle it. A stress test keeps increasing traffic until something breaks, to find the ceiling.
What is a soak test? A load test that runs for several hours at steady load to find slow problems such as memory leaks, connection leaks and disks filling up.
How long before Black Friday should I load test? Early enough to fix what you find and test again before your change freeze. For most teams, that means the first half of November at the latest.
Can I load test production? Test a copy of production where you can. If you must test production, do it at a quiet time, at a capped level, and warn your providers first.
Danish Rumane writes about hosting and cloud technology with a focus on what it means for businesses. His perspective draws on more than a decade in marketing, building brands and creating content across industries.
Keep reading
Let’s map your infrastructure to the right plan
A free 30-minute call with our cloud team. We review your current environment and show you exactly what a move to InMotion Cloud would look like: timeline, architecture, and cost.