The value of soak testing

Average-load and baseline tests show how the system behaves under expected traffic for a short window. Soak testing reuses that load level and holds the plateau longer so degradation that needs time to accumulate becomes visible.

Stress and spike tests answer overload and burst questions. Soak testing answers a duration question: does performance or stability drift when load stays near average levels for hours?

Problems short runs miss

A five-minute stress run cannot expose a leak that adds 50 MB per hour. A ten-minute breakpoint ramp may not reveal a connection pool that loses handles only under sustained traffic. Those defects need a longer plateau at moderate load.

Common patterns soak tests target:

• Memory leaks: Allocations that are never freed. Server memory climbs; http_req_duration in k6 may rise if garbage-collection pauses or queueing increase. Confirm with application memory metrics on the system under test.
• Connection pool limits: Connections acquired but not returned under certain errors. Short tests look healthy; after hours, new requests block and latency or errors increase.
• Log and disk fill: Verbose logging or temp files that grow without rotation. Performance can change suddenly when disk space runs out.
• Gradual latency creep: Fragmented indexes, full caches, or backlog growth. p95 drifts upward slowly enough that point-in-time alerts never fire.

How soak differs from other test types

In k6 docs, soak is a variation of average-load testing: same ramp-up and ramp-down pattern, longer plateau. Load stays near the average level you measured in baseline work, not at stress-test peaks.

In the next milestone, you design a soak profile with that longer plateau.