Stress testing an API: find the breaking point

What a stress test is

A stress test deliberately goes past what you expect. The load climbs beyond the number you set — in Stabula, to twice it — and keeps climbing until something gives way.

The point is not to pass. The point is to learn which part fails first, whether it fails gracefully, and at what number, so you know how much headroom you actually have rather than how much you hope you have.

When to run one

• Before a launch, a campaign, or anything else that might arrive all at once.
• After adding capacity, to confirm the ceiling moved and to find the new one.
• When you need a real number for a capacity plan rather than an estimate.

What to read in the report

Where the error rate turns

The user count at which errors start is your practical ceiling, whatever the box can theoretically serve.

How it fails

Timeouts, refused connections and 5xx mean different things. The report names each, grouped by cause and host.

Whether it recovers

As the run ramps down, does the error rate fall back? A system that stays broken after the peak has a queue that never drained.

Running one in Stabula

Build the request in the editor — URL, headers, auth, body — choose Stress 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.