Soak / endurance test

A soak test — also called an endurance test — holds your system under a normal, realistic load for a long time: typically 2 to 12 hours, sometimes overnight. The load level is not extreme; the duration is. Soak tests reveal problems that only emerge 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. There is no point running an 8-hour soak if the 15-minute load test already shows errors.
• The target environment will not be needed for other work during the run window.
• Monitoring / alerting is set up so the ops team is notified 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 — you are not trying to stress the system — but holds it 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

The metrics to watch are not peak values but drift: does p95 latency slowly climb over hours? Does throughput quietly decline? Does the error rate tick upward in the last hour that was 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

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

2. Modify 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)}}"}'

3. In Load profile, set Virtual users to 50, Ramp-up to 3m, and Duration to 8h.

4. Optionally configure a Failure criteria on error rate (e.g., error rate > 1 %) so the run automatically fails if a leak causes cascading errors mid-run.

5. Click Run. The run will be visible in the runs list with a running status for the full duration. You do not need to watch it continuously — MaxoPerf streams results the whole time.

Tip

Use MaxoPerf’s scheduled runs to trigger your overnight soak automatically. Set the schedule to fire at, say, 22:00 on Thursdays so the result is ready to review Friday morning. See Schedule recurring tests.

How to read the result

Open the Overview tab after the run and focus on the time dimension:

• Latency trend — is p95 flat across the full duration, or does it slowly creep upward over hours? Even a 20 % drift in p95 over 8 hours signals a likely memory or resource leak.
• Throughput — should be flat. A declining 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). This timing pattern is characteristic of resource exhaustion.

When you find drift, correlate the time range with your application metrics (CPU, heap, GC pause, open file descriptors) to pinpoint 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” — that is a stress test
Watch for drift, not peak values	Declare the soak passed just 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

Caution

Long-running tests consume runner capacity for their full duration. Check your workspace runner limits before starting a multi-hour soak. If you are using managed cloud runners, the run time counts against your usage.

Where to go next

• Breakpoint / capacity test — find the absolute ceiling, not just long-term stability.
• Cookbook: Overnight soak test — a complete recipe including schedule configuration and result review workflow.
• Foundations: Baselines, SLOs, and error budgets — understand how to define acceptable drift thresholds.