What is Soak Testing?

A short load test can pass while a system is quietly broken. Soak testing exists because some failures are time-dependent: a small memory leak that is invisible in a ten-minute run will crash the service after twelve hours; a connection or file handle that is never released will eventually exhaust the pool; logs or caches that grow unbounded will fill the disk; and response times can creep upward as garbage collection or fragmentation accumulates.

The method is to apply a realistic, sustained load (not a peak, but normal expected traffic) and watch trend lines over a long window: memory, CPU, connection counts, response times, and error rates. The signal you are hunting is a slow drift, anything that is not flat over time is suspect. Soak tests are usually run in a production-like environment with good observability, because without metrics over time you cannot see the slope.

It sits in the performance-testing family alongside load testing (behavior at expected and peak load), stress testing (beyond capacity to find the breaking point), and spike testing (sudden sharp changes). Soak is the one that catches the bugs a clock reveals.

Keep the four performance test types straight with two axes: intensity and duration. Load testing applies expected and peak traffic for a short window (commonly 30 to 60 minutes) to validate throughput and response-time targets. Stress testing pushes past capacity until something breaks, to find the ceiling and observe the failure mode. Spike testing changes load abruptly, jumping to many times normal within seconds, to test elasticity and recovery. Soak testing holds normal load flat for a long window: 8 to 24 hours is typical for release gating, while telecom, medical, and infrastructure teams commonly run 48 to 72 hours before major releases.

The defect classes soak testing catches are specific and worth naming. Memory leaks show up as a steady upward heap or RSS trend that survives garbage collection. Connection-pool exhaustion appears when database or HTTP connections are opened per request and never returned, so throughput collapses hours in. Unbounded log growth and temp-file accumulation fill disks, and cache bloat sets in when caches lack TTLs or eviction, degrading hit rate and memory at once. Slower burns include file-descriptor and thread leaks, scheduled-job pileups, session-store growth, and counter- or clock-related bugs that only fire after a threshold of elapsed time.

Tooling is the easy part: k6 models a soak with a constant-vus executor or a stages profile that holds, say, 400 virtual users for 12 hours; JMeter uses a long-running thread group driven from CI in non-GUI mode; Gatling defines a constantUsersPerSec injection profile over hours. The discriminating skill is instrumentation: pair the load generator with dashboards (Grafana with Prometheus, or Datadog) and watch heap and RSS memory, GC pause frequency, connection-pool utilization, file descriptors, disk usage, p95/p99 latency, and error rate as trend lines. The pass criterion is not a number but a shape: every curve should be flat after warm-up, and any consistent slope is a finding.