Glossary · Performance
Soak testing
Also called: soak test, soak tests, endurance testing, endurance test
Definition
Performance testing that holds a normal, realistic load for many hours to expose problems that only build up over time, such as memory leaks.
Soak testing (also called endurance testing) runs a system at a normal, sustained load for a long period, typically several hours and sometimes a day or more. The load itself is unremarkable; the duration is the point. Many defects are invisible in a 10-minute load test because they grow slowly: a few megabytes leaked per thousand requests, a connection that is never returned to the pool, a log file that fills the disk.
What it finds
- Memory leaks. Heap usage that climbs steadily and never comes back down after garbage collection, eventually ending in an out-of-memory crash.
- Resource exhaustion. Database connections, file handles, threads or sockets that are opened and not released.
- Gradual latency drift. p95 at hour six is noticeably worse than at hour one, often from growing caches, table bloat or fragmentation.
- Scheduled-job interference. Nightly batch jobs, backups, certificate renewals or log rotation colliding with live traffic.
- Storage growth. Disks filling with logs, temp files or queue backlogs.
Example (k6)
export const options = {
stages: [
{ duration: '10m', target: 80 },
{ duration: '8h', target: 80 },
{ duration: '10m', target: 0 },
],
thresholds: {
http_req_duration: ['p(95)<600'],
http_req_failed: ['rate<0.005'],
},
};
The default function is the same realistic user journey you would use for a load test. The difference is the long steady stage.
How to read the results
A soak test is judged on trends, not just pass/fail thresholds. Plot memory, connection counts, latency percentiles and error rate over the whole run. A flat line is a pass. A steady upward slope is a defect, even if the run ended before anything crashed, because production runs far longer than eight hours.
Common mistakes
- Running the soak at stress-level load, which mixes two questions and makes the cause of a failure unclear.
- Watching only client-side metrics. Leaks show up first in server memory and pool graphs.
- Using an environment that restarts services or autoscales them away during the run, which hides exactly the build-up you are looking for.
- Skipping it because it is slow. Schedule it overnight or at weekends rather than dropping it.