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 | Response times held steady up to N, then degraded above it. The level named is the highest one that held. |
| Degraded from the lowest level measured | The very first load level already failed, 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. |
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.
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.
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 decreased over the run rather than increasing.
- 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. Support for multi-generator runs is planned.
- 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, 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.