RESOURCES
Soak test
A soak test holds steady authorized load for a longer window to find leaks, queue growth, and slow degradation that short spikes miss.
Definition
A soak test (endurance test) applies a sustained, usually moderate-to-peak-realistic load for an extended period — often tens of minutes to hours — watching for memory leaks, connection pool exhaustion, disk fill, cache stampede patterns, and gradual latency drift.
Unlike a spike test, the point is not a sudden jump; it is whether the system stays healthy for as long as a real peak is expected to last. Duration should match the business window (campaign hour, match length, nightly batch), not an arbitrary “run forever.”
Related: abort criteria, throughput.
Why it matters for authorized load testing
Many production incidents appear after forty minutes of “fine,” not at second thirty. Authorized soak runs on owned infrastructure catch sticky queues and resource leaks while you still control the blast radius and can stop instantly.
Without soak coverage, teams ship on the strength of a ten-minute spike and discover degradation only when customers arrive. Keep cool-down after stop to see whether recovery is clean.
How Slammed.st uses it
Choose a plan whose max duration covers your soak window, verify the target, set abort rules for latency and errors, and run a steady L7 (or appropriate L4) profile from the Hub. Multi-region sources can make long runs more realistic for edge behavior — still only on authorized assets.
Glossary cluster
Browse related term pages and the hub glossary:
What soaks catch that spikes miss
A soak test holds steady load long enough to expose memory leaks, queue growth, connection pool exhaustion, certificate refresh issues, and slow degradation. Spikes answer “what breaks immediately?”; soaks answer “what rots after the graph looks fine?” Duration should resemble how long your real peak is expected to last — not an arbitrary overnight vanity run without abort rules.
Compare spike test. Abort discipline: abort criteria. Hub: authorized load testing.
Soak sequence for authorized Hub runs
- Pick a stable concurrency below the known cliff from earlier capacity steps.
- Verify target and notify on-call for the full window length.
- Hold load; sample latency, errors, and host memory/FD metrics on a fixed cadence.
- Abort early if budgets breach — finishing the clock is not the goal.
- Cool down and inspect whether the system returns to baseline.
Plan duration limits matter — see pricing. Practice on trial. Sizing: concurrent vs RPS.
When not to soak
Do not soak at a concurrency already known to fail. Do not soak production during unrelated incidents. Do not soak third-party systems. If you only need autoscaler reaction to a jump, schedule a spike with tight aborts instead.
Related
Resources hub · Glossary · Tools matrix · RPS calculator · Useful network tools · Blog · Pricing · Start free