Spike test

A spike test simulates a sudden, large jump in traffic, like the one you get when a marketing email goes out, a high-traffic site features your product, or a flash sale opens. A stress test ramps gradually. A spike test jumps to a very high load almost instantly. It measures how the system behaves during the surge and, most important, whether it recovers cleanly afterward.

Before you start

A load test has already established your baseline behaviour at expected peak load.
Stakeholders know that a spike run may cause elevated errors or temporary unavailability on the target system.
Run against staging, not production.

What is a spike test?

A spike test has a recognisable shape:

Low baseline. A short period at normal load (e.g., 10 VUs for 1 min) gives you a clean starting point.
Instant surge. A near-instant ramp to a very high VU count (e.g., 500 VUs in under 30 seconds) simulates a flash-traffic event.
Brief hold. Hold at the spike peak long enough for autoscaling or circuit breakers to respond (1–3 min).
Drop and recovery. Traffic returns to baseline. Watch whether the system recovers or keeps showing errors.

A spike test answers these questions:

Does the system stay alive (no 5xx cascade) during the surge?
If errors occur, do they stop once traffic drops back?
How long does recovery take?

How to run a spike test in MaxoPerf

Load profile

Parameter	Value
Baseline VUs	10–20 (1 min)
Spike VUs	500–1000 (5×–20× normal)
Ramp to spike	10–30 s (very fast)
Hold at spike	1–3 min
Recovery ramp-down	Back to baseline in 30 s
Total duration	~8–10 min

Console walk-through

Create a new test named api-spike based on the same scenario as your load test.

For a spike profile in Taurus, use a stages configuration:

execution:
  - executor: jmeter
    concurrency:
      - const: 10
        duration: 1m
      - const: 500
        duration: 3m
      - const: 10
        duration: 2m
    scenario: api-spike

scenarios:
  api-spike:
    requests:
      - url: https://api.staging.example.com/v1/products
        label: list-products

This holds 10 VUs for 1 minute, jumps to 500 VUs for 3 minutes, then drops back to 10 VUs for a 2-minute recovery observation window.

In Load profile, use the duration stop mode and set Duration to the total scenario length (6m).
Select the same location(s) as your load test.
Click Run and watch the live Overview tab. The VU surge and its effect on latency show up in real time.

How to read the result

Open the Overview tab after the run:

Throughput. It should spike with the VU surge. Flat throughput while VUs rise means the system is queuing requests internally.
p95 latency. Look for the latency spike that lines up with the VU surge. A sharp climb that recovers quickly after the VU drop means the system is resilient.
Error rate. Errors during the surge are expected if the system auto-scales. Errors that continue after the VU drop mean recovery is slow or failed.
Runners tab. Confirm all runners were in running state during the surge. Runner failures during a spike run make the result unreliable.

If the error rate stays high after the VU count drops back to baseline, the system has not recovered. Look at connection pool exhaustion, circuit breaker state and downstream service backpressure.

Do / don’t

Do	Don’t
Include a recovery window after the spike (2 min minimum)	End the run right after the spike peak and miss the recovery data
Compare the spike result against the load-test baseline	Spike a system that has not passed a load test first
Watch for slow recovery (errors persisting post-spike)	Conclude the system “passed” only because it survived the spike
Alert ops before running on shared infrastructure	Spike production without a maintenance window

Where to go next

Soak / endurance test: the opposite case, normal load held for hours.
Stress test: a gradual ramp to find the breaking point.
Cookbook: Spike and recover: a step-by-step MaxoPerf recipe for a spike + recovery scenario.
Foundations: Ramp-up, think time, and pacing: how ramp speed affects results.