Soak Tests
Soak tests hold a realistic load for hours or days to expose memory leaks, resource exhaustion, and gradual degradation that short runs miss.
Definition
A soak test applies sustained, moderate load over an extended period to reveal time-dependent failures such as leaks, fragmentation, and connection exhaustion.
Context and scope
Used before long-running releases, for services with caches and connection pools, and wherever uptime is measured in weeks rather than minutes.
Common misconceptions
- Soak testing is the same as stress testing
- A one-hour run is long enough to find meaningful leaks
- Soak tests must use maximum load to be useful
Anti-patterns
- Running at peak load and calling the result endurance testing
- Watching only error rates while ignoring memory and file descriptors
- Testing one instance when production runs a fleet
Related concepts
Related examples
Authoritative source
https://grafana.com/docs/k6/latest/testing-guides/test-types/soak-testing/
What soak testing finds
A soak test, also called an endurance test, runs a steady and realistic load for hours or days. Many defects only appear with time: a cache that grows without eviction, a connection pool that leaks one connection per failed request, a log buffer that fills disk, a heap that fragments until garbage collection pauses lengthen. Short load tests finish before these effects mature, so they report healthy numbers while production degrades over a weekend.
Load profile
Use a moderate, production-like mix rather than maximum throughput. The goal is duration, not peak. Include background jobs, scheduled tasks, and periodic reconnects, because those often trigger leaks. A common pattern is a ramp to expected load, a long plateau, and a short ramp down, with the soak lasting long enough to cross at least one daily cycle. Compared to a spike test, which stresses sudden change, a soak test stresses persistence.
What to measure
Track memory and garbage collection behavior, open file descriptors, thread or worker counts, connection pool saturation, disk usage, and latency percentiles over time. A slowly rising p99 with flat throughput is a classic sign of degradation. Watch downstream systems too: a soak test can exhaust a shared database or fill a queue that another service depends on. Alert on trend, not only on thresholds.
Duration and cadence
There is no universal duration. A service with known slow leaks may need twenty-four hours; a batch pipeline may need several runs. Run soak tests before major releases, after dependency upgrades, and on a schedule in a production-like environment. Keep them out of the fast feedback loop.
Limits
Soak tests are expensive and cannot prove the absence of leaks. For example, a leak that appears only under a rare request mix may survive a clean run. Pair endurance testing with heap profiling and production memory alerts.