Load profiles: soak, spike, stress, breakpoint

Most teams run one load test, call it "performance testing," and move on. But a single test with a single shape can only answer a single question, and that question is rarely the one that matters most in production. A memory leak that takes six hours to show up will sail through a five-minute test looking perfectly healthy. A traffic spike from a launch announcement fails differently again, and a slow creep toward a hard ceiling fails differently still. Four load profiles below, each aimed at one specific way production traffic actually breaks a system, and none of them a substitute for the others.

This is also why a performance test that only reports percentiles from one shape of load is incomplete. A p99 that looks fine under a soak profile can look completely different under a spike.

Soak: does it leak over time

A soak test holds a steady, moderate load for hours rather than minutes. It exists to catch problems that only accumulate: memory leaks, unclosed database connections, log files filling a disk, a cache that never evicts. None of these show up in a short burst; they need time to compound into something visible.

The failure mode a soak test is built to catch looks fine at minute ten and degraded by hour six. If your memory graph trends steadily upward instead of settling into a flat line, that is the soak test doing its job.

Spike: does it survive sudden traffic

A spike test jumps load from normal to several times normal almost instantly, then holds or drops it, to mimic what happens when a marketing email goes out, a product gets mentioned somewhere popular, or a scheduled job fires for every customer at once. The question is not whether the system handles the peak gracefully forever; it is whether it survives the transition without falling over, and how quickly it recovers once the spike passes.

Autoscaling that takes ninety seconds to add capacity is invisible in a normal load test and is exactly what a spike test exposes, because those ninety seconds are where requests queue up and start timing out.

Stress: where does it actually break

A stress test increases load steadily until something fails, rather than stopping at an expected ceiling. The goal is not to prove the system survives; it is to find out what breaks first, and how.

A checkout service once passed every load test run against its own API. Under a real stress test that also hit its payment gateway dependency, the gateway's connection pool exhausted at 1,200 concurrent requests, three hundred requests before the checkout service itself showed any strain. The bottleneck was never where the team was looking.

Breakpoint: the number after which you stop guessing

A breakpoint test is closely related to a stress test but framed differently: instead of watching for a failure, you are hunting for the specific number, the exact concurrent user count or requests-per-second figure where latency crosses an unacceptable threshold or errors start climbing.

That number becomes a real capacity planning input instead of a guess pulled from a previous incident, and it reflects the same discipline as reading performance results by percentile rather than by average.

Run the breakpoint test again after any significant infrastructure or code change. The number moves, sometimes in the direction you would not expect, and a team that never re-measures it is planning capacity against a fiction.

Picking the shape for the question you actually have

Choosing the wrong profile answers a question nobody asked. Match the profile to the risk you are actually worried about this quarter:

• Worried about a slow degradation over hours or days? Run a soak test.
• Expecting a traffic surge from a launch, ad, or scheduled event? Run a spike test.
• Need to know what fails first as load climbs? Run a stress test.
• Need an exact capacity number for planning? Run a breakpoint test.

A spike test tells you nothing about a slow memory leak, and a six-hour soak test is a poor way to find out whether a launch-day traffic surge will survive.

FAQ