Soak test
Holding realistic traffic for hours to catch memory leaks, exhausted connection pools, and other failures that appear slowly.
What it is
A soak test holds a realistic, steady load for hours rather than chasing a dramatic peak. The long clock is the test. It gives memory leaks, abandoned database connections, unbounded queues, log growth, and cache churn enough time to become visible. k6, Gatling, JMeter, and Locust can all drive one.
Run a soak before a major launch or after changing connection pools, caches, background workers, or anything that owns a resource over time. Graph latency and errors beside process memory, open connections, queue depth, and restarts, then compare the first stable hour with the last.
Gotcha: a long run is not automatically a useful run. If traffic is unrealistic, test data runs out, or monitoring keeps only fifteen minutes of history, you have paid eight hours to learn nothing. Warm the system first, keep the load below saturation, and define what counts as unacceptable drift before starting.
Ask AI for it
Write an eight-hour k6 soak test using the `constant-vus` executor at the service's measured normal concurrency. Add thresholds for `http_req_failed` and p95 `http_req_duration`, tag the main endpoints, and export results to Prometheus for a Grafana dashboard. Plot request rate, latency, errors, process RSS, heap use, database pool wait time, open connections, queue depth, and pod restarts. Compare the first and last stable hours and fail the run when latency, memory, or resource counts show sustained upward drift beyond stated limits.