Load vs. Stress vs. Soak vs. Spike Testing: Which One to Run Before Your Next Black Friday
“We ran a load test” doesn’t say much on its own. Did you run it at the average traffic you expect, or double that? Did you hold it for ten minutes or six hours? Did you ramp up gradually or throw a traffic spike at it with no warning? Each of those questions defines a different test type, with a different goal and a different failure it’s built to expose. Confusing them isn’t a semantic detail — it’s the difference between walking into Black Friday with real data or with the illusion that “we already tested this.”
What each load test type actually is
Load, stress, soak, and spike are four distinct load profiles, each designed to expose a different kind of failure — they aren’t interchangeable synonyms for “we threw traffic at it.”
- Load testing (or average-load testing): measures how the system behaves under the traffic you expect on a normal day. The profile ramps up gradually to typical user volume, holds it for a while, then ramps down. It answers: “does it hold up on an average day?”
- Stress testing: measures how stable the system is once load goes above normal — sometimes a modest increase, sometimes 50-100% or more, depending on the risk scenario you’re evaluating — sustained for 5 to 60 minutes with a gradual ramp-up. It answers: “how far above normal can it go before it degrades?”
- Soak testing (or endurance testing): measures what happens to the system under sustained normal load for hours or even days. It’s not looking for a breaking point — it’s looking for memory leaks and slow degradation that only show up over time. It answers: “does it hold up on a normal day… sustained for a whole week?”
- Spike testing: measures the system’s resilience against a sudden, extreme traffic surge, with little to no ramp-up, held for just a couple of minutes. It answers: “does it survive if we go viral tomorrow with no warning?”
Why it matters: almost nobody runs all four
It matters because every test type you skip is a failure scenario you’ll discover in production instead of in a controlled environment — and on a peak date like Black Friday, that discovery is expensive.
24%
of retail executives have no plan if their site goes down on a peak date
40%
have already had a site outage in the past three years
143K
dollars lost in an 8-hour outage — real case, Black Friday 2015
Sources: Google Cloud survey cited by Retail Dive; case documented by Rewind (Shopify data).
Most teams that “test before Black Friday” run exactly one of the four: load testing at expected traffic. It’s necessary, but it doesn’t explain why a system that passed that test still goes down — because the real failure never lived in the scenario that got tested. The athletic apparel retailer’s case is literal: 8 hours of Black Friday 2015 downtime cost it an estimated $143,000 in lost sales, with an integrated third-party vendor as the root cause — exactly the kind of breaking point a stress test, not a load test, is built to catch before it happens live.
Why running the wrong test type leaves you blind
It leaves you blind because the same system can pass a load test cleanly and still go down on Black Friday, for a reason that test was never designed to find.
- A load test at average traffic tells you nothing about 2x or 5x traffic — that data only comes from a stress test, and that’s exactly the Black Friday scenario.
- Black Friday isn’t a day anymore, it’s a week (Cyber Week). Without soak testing, a memory leak that takes six hours to surface goes unnoticed in a twenty-minute test and shows up in production halfway through peak sales week instead.
- An email campaign or a viral mention doesn’t follow any gradual ramp — that’s exactly the scenario a spike test reproduces and a load test doesn’t.
- This isn’t a tooling problem, it’s a judgment problem. Most teams already have k6, JMeter, or Gatling installed. What’s missing isn’t the tool — it’s running all four profiles against the critical flow, not just the first one.
How we do it: four profiles, one script
With k6, all four test types are the same tool with different scenarios
— you don’t rewrite the test, just the load profile:
import http from 'k6/http';
import { sleep, check } from 'k6';
export const options = {
scenarios: {
// Load / average-load: typical traffic, sustained, smooth ramp
load: {
executor: 'ramping-vus',
startVUs: 0,
stages: [
{ duration: '2m', target: 500 },
{ duration: '10m', target: 500 },
{ duration: '2m', target: 0 },
],
},
// Stress: well above normal, looking for the breaking point
stress: {
executor: 'ramping-vus',
startVUs: 0,
startTime: '15m', // runs after "load"
stages: [
{ duration: '5m', target: 1500 }, // ~3x typical traffic
{ duration: '20m', target: 1500 },
{ duration: '5m', target: 0 },
],
},
// Soak: normal load sustained for hours — looking for leaks, not peaks
soak: {
executor: 'constant-vus',
vus: 500,
duration: '4h',
startTime: '45m',
},
// Spike: no ramp, all at once — the email blast or the viral post
spike: {
executor: 'ramping-vus',
startVUs: 0,
startTime: '4h45m',
stages: [
{ duration: '30s', target: 3000 }, // 6x typical traffic, no warning
{ duration: '3m', target: 3000 },
{ duration: '30s', target: 0 },
],
},
},
};
export default function () {
const res = http.get('https://your-store.example.com/checkout');
check(res, { 'checkout responds 200': (r) => r.status === 200 });
sleep(1);
}What changes between the four isn’t the request being tested — it’s how many people, with what ramp, and for how long. Running all four against the same critical flow — login, cart, checkout — is what separates “we tested it” from “we know exactly where it breaks and when.”
If your next high-traffic event is Black Friday, a launch, or a campaign with an expected spike, and your last load test was “we simulated normal traffic and it didn’t fall over,” that’s exactly the kind of gap we close with tailored performance engineering projects.
Does your load test only cover one of the four scenarios that matter?
Let’s talk about a testing plan that covers load, stress, soak, and spike before your next traffic peak.