Skip to content

Reading a scaling report

When a load test finishes, open its report to see how the target behaved as the load rose. This page walks through each metric and what it tells you.

How long requests took to complete, shown as a distribution rather than a single number. A tight distribution means consistent performance; a long tail means some requests were much slower than the rest — often the first sign of strain.

The same timing data summarized as percentiles:

  • p50 — the median. Half of requests were faster than this.
  • p90 — nine in ten requests were faster than this.
  • p99 — your slowest one percent. This is what your worst-affected users actually experienced.

Watch the gap between p50 and p99. A low median with a high p99 means most users are fine but a meaningful minority are seeing painful delays.

The proportion of responses that failed, broken down by HTTP status. This tells you not just how many requests failed but how — for example a rise in 5xx errors points to the server falling over under load, while 4xx errors may point to throttling or auth limits being hit.

How many requests the target successfully served per unit of time. Throughput that climbs with load and then flattens (or drops) marks the point where the target stops keeping up.

A view of how the mix of response codes shifts as the virtual-user count increases. This is the most direct read on capacity: the virtual-user level where successful responses give way to errors is, in practice, your ceiling.

  • Healthy under load — response times stay flat, errors stay near zero, and throughput tracks the load. You have headroom.
  • Approaching the limit — p99 climbs while p50 stays low, throughput flattens. You’re nearing capacity.
  • Past the limit — error rates climb (especially 5xx) and throughput falls. The target can’t serve the offered load.
  • Running a load test — adjust the load and run again to confirm a fix or find the next limit.