What is Soak Testing?

What is soak testing?

Soak testing (also called endurance testing) runs moderate, sustained load against a system for many hours or days, far longer than a typical load test. The goal isn't to find the capacity ceiling or stress-break the system. It's to surface slow-developing problems that only manifest after hours of operation: memory leaks, connection-pool drift, log-disk fill, certificate expiry, database connection thrashing, slow cache eviction patterns.

Soak testing vs load testing

A load test runs at expected peak for 15 minutes to a few hours — long enough for caches to warm and for short-term behaviour to stabilise. A soak test runs at maybe 40-60% of peak for 8-72 hours — long enough that gradually-accumulating problems become visible.

The questions each answers differ:

• Load test: can my system meet SLOs at expected peak for an hour or two?
• Soak test: if I run my system at moderate load continuously for two days, does performance stay stable, or does it slowly degrade?

Soak tests intentionally run below peak to surface accumulating issues. To find the maximum sustained load itself, see capacity testing.

What soak tests find

Things short load tests miss:

• Memory leaks. An object never garbage-collected, a buffer never freed, a cache that grows unbounded. Heap grows over hours until the JVM (or Node, Go, Python) hits a limit and the process dies.
• Connection-pool drift. Database or HTTP-client connection pools that leak one connection per N requests, eventually exhausting available slots.
• Log-disk fill. Verbose logging eats disk; production runs out of space after hours.
• Certificate or token expiry. An OAuth token cached for 1 hour; if not refreshed correctly, all requests after the hour fail.
• Slow cache eviction. Cache hits stay high for a while, then drop as the working set rotates; performance silently degrades.
• Resource exhaustion that compounds. Database temp tables, message-queue backlogs, file descriptors.

When to run a soak test

• Pre-major-release. A new persistent service, framework upgrade, or database migration introduces unknown long-term behaviour.
• After architecture changes. New caching layer, new message queue, new database driver, new service-mesh sidecar.
• Quarterly, as a regression check. Most teams run soak tests less often than load tests; quarterly catches slow drift between releases.
• Post-incident. If an outage was caused by a slow leak, a soak test against the fix confirms the leak is gone.

Key soak-test metrics

1. Memory usage trend over time. Heap should plateau, not climb linearly. Climbing memory = leak.
2. Response-time percentile drift. p95 at hour 24 should match p95 at hour 1.
3. Resource pool utilisation. DB connection pool, HTTP client pool, thread pool — should stay flat, not climb.
4. Error rate over time. Should stay constant. Sudden uptick at hour N = an accumulating problem just crossed a threshold.

How to run a soak test

Same scripts as load testing, longer duration. In JMeter, set the Thread Group duration to many hours (24-72). In k6, configure a constant-vus scenario with a long duration setting.

For multi-day soak tests where the test-harness itself can't run continuously on a laptop, run from LoadFocus. The cloud infrastructure handles the long-running session without local machine constraints.

If your team doesn't have time to set up and monitor multi-day soak runs, LoadFocus offers load testing services where engineers run the soak, monitor the metrics, and deliver a report.