Spike testing: a sudden burst of API traffic

What a spike test is

A spike test skips the ramp. Load jumps to several times the baseline within seconds — in Stabula, three times the users you set — holds briefly, and drops away again.

This is the shape real traffic takes when a campaign email goes out, a post does well, or a scheduled job in someone else's system fires. Autoscaling that copes fine with a gradual climb often cannot react to a burst, because the new capacity arrives after the burst is over.

When to run one

• Before an announcement, a launch, or a send to a large list.
• When your platform autoscales and you want to know how long it takes to react.
• After adding a cache or a queue, to see whether it absorbs the burst or collapses under it.

What to read in the report

The first seconds

Errors concentrated at the start of the spike mean nothing warmed up in time — a cold cache, a connection pool, a scale-up that arrived late.

p99 against p95

A spike shows up in the tail first. A p99 far above p95 means a minority of requests suffered badly while the average looked fine.

Recovery

The run drops back deliberately. If errors continue after the load has gone, something is still catching up.

Running one in Stabula

Build the request in the editor — URL, headers, auth, body — choose Spike Test, and the settings below are filled in for you. Change any of them; the load profile under them redraws, and the estimate says what the run will cost against your month's allowance before you start it.

The run itself happens in an isolated container on our infrastructure, not in your browser, and the report is written in sentences rather than percentiles alone: which targets were met, which checks failed, and what the runner hit — grouped by cause and host.