Soak / endurance test

A soak test, also called an endurance test, holds your system under normal, realistic load for a long time: typically 2 to 12 hours, sometimes overnight. The load level is ordinary. The duration is what’s extreme. Soak tests find problems that only show up over time, such as memory leaks, file descriptor exhaustion, connection pool depletion and gradual latency drift.

Before you start

Your system passes a load test at the same VU count. An 8-hour soak is pointless if the 15-minute load test already shows errors.
Nobody else needs the target environment during the run window.
Monitoring and alerting are set up, so the ops team hears about it if the target falls over mid-run.

What is a soak test?

A soak test uses the same VU count as your regular load test, because you are not trying to stress the system. It holds that count for much longer:

Variant	Duration	Good for
Short soak	2 h	Initial check for fast leaks
Overnight soak	8–12 h	Standard production validation
Extended soak	24–72 h	Pre-release sign-off for long-lived services

Watch for drift rather than peak values. Check whether p95 latency climbs slowly over hours, whether throughput declines, and whether the error rate rises in the last hour after staying flat in the first.

How to run a soak test in MaxoPerf

Load profile

Parameter	Value
Virtual users (VUs)	Same as your load-test baseline (e.g., 50–100)
Ramp-up	2–5 min (same gradual ramp as load test)
Hold duration	2–12 h (or longer)
Stop mode	Duration
Locations	Same as load test

Console walk-through

Duplicate your load test and rename it api-soak-8h (or reflect the actual duration).

Edit the Taurus YAML. The only change from a load test is the hold-for value:

execution:
  - executor: jmeter
    concurrency: 50
    ramp-up: 3m
    hold-for: 8h
    scenario: api-soak

scenarios:
  api-soak:
    requests:
      - url: https://api.staging.example.com/v1/products
        label: list-products
      - url: https://api.staging.example.com/v1/cart
        label: view-cart
        method: POST
        body: '{"userId":"soak-user-{{__Random(1,500)}}"}'

In Load profile, set Virtual users to 50, Ramp-up to 3m, and Duration to 8h.
Optionally, add a Failure criteria on error rate (e.g., error rate > 1 %) so the run fails automatically if a leak sets off a wave of errors mid-run.
Click Run. The run shows in the runs list with a running status for the full duration. You do not need to watch it: MaxoPerf streams results the whole time.

How to read the result

Open the Overview tab after the run and look at how metrics change over time:

Latency trend. Check whether p95 stays flat for the full duration or creeps up over hours. Even a 20 % drift in p95 over 8 hours points to a likely memory or resource leak.
Throughput. It should be flat. Falling throughput at constant VUs suggests the system is slowing down (garbage collection pauses, lock contention, DB query degradation).
Error rate. Check whether errors appear only after a certain time (for example, after 4 hours). That timing is typical of resource exhaustion.

When you find drift, line up the time range with your application metrics (CPU, heap, GC pause, open file descriptors) to find the root cause.

Do / don’t

Do	Don’t
Run the soak on a system that already passes a load test	Run a soak test before establishing a load-test baseline
Use the same VU count as your load test	Increase VUs to “make it more interesting”, which turns it into a stress test
Watch for drift, not peak values	Declare the soak passed only because no errors occurred
Schedule the run overnight via MaxoPerf schedules	Leave the team watching a live dashboard for 8 hours
Correlate latency drift with application-level metrics	Treat a clean soak run as a complete health proof

Where to go next

Breakpoint / capacity test: find the absolute ceiling rather than long-term stability.
Cookbook: Overnight soak test: a full recipe, including schedule configuration and how to review the result.
Foundations: Baselines, SLOs, and error budgets: how to define acceptable drift thresholds.