Reading the Capacity Panel
When a load test finishes, the results page opens with a plain statement of what happened, above the charts:
Stable to ~400 users
p95 more than doubled above 640 - 0.5% errors there
The sentence is measured, not estimated. LoadFocus groups the run's results by the number of virtual users that were active, then reads the curve. Nothing is inferred from the target you configured, and no AI writes it.
What the panel can say
| Reading | What it means |
|---|---|
| Stable to ~N users | Error rate and response times held up to N, then degraded above it. The level named is the highest one that held. |
| Degraded from the lowest level measured | The error rate was already above 1% at the very first load level, so there is no healthy level to report. |
| No degradation up to N users | Every level behaved. The run did not find a limit, which is not the same as proving there isn't one. |
| Degraded and recovered | Something struggled mid-run and then behaved again at higher load, so no single limit can be read from it. |
| (nothing shown) | The run does not support a conclusion. See below. |
On a paid plan, expand By user level to see the per-level breakdown behind the sentence: p95, requests per second and error rate at each virtual-user level. Free plans see the sentence and a link to upgrade for the breakdown.
If the results were capped, the sentence ends with "(results were capped, so the top level may not be the peak)".
When the panel says nothing, and why
This is the normal case for many tests, and it is deliberate. LoadFocus would rather show nothing than name a capacity limit it cannot support. On a paid plan, a run that was measured but had too few levels shows a short note, "Capacity: too few load levels to judge", above the per-level table instead.
The panel stays quiet when:
- The test did not ramp. A run that holds a constant number of users has no curve to read. You need load that increases over time.
- There were fewer than three distinct user levels, or the highest level was less than double the lowest. Two nearby points are not enough to tell a trend from noise.
- Load did not increase over the run. It stayed flat or went down.
- Response-time data is missing for some levels. A verdict drawn from a partly empty column would be a guess.
- The test used more than one load generator. Each generator reports its own user count, so combining them would misstate both the load and the throughput.
- The test is still running. The panel appears once the run finishes.
Getting a capacity reading
To produce a "stable to ~N users" answer, configure a test that ramps: start low, increase the number of virtual users over the duration (see Ramp Up Time and how to set up a new load test), and give each level enough time to produce a stable measurement. A run that steps from 100 to 1,000 users over several minutes will produce a reading; a flat run at 500 users will not, however long it lasts.
How degradation is decided
A level counts as degraded when either:
- its error rate rises above 1%, or
- its p95 response time is more than double the best level measured in the run.
A brief spike that recovers at higher load is not treated as a limit. If the system is healthy again further up the curve, the run is reported as degraded and recovered rather than given a false ceiling.