What is Capacity Testing?

What is capacity testing?

Capacity testing measures the maximum sustainable load a system can handle while still meeting its service-level objectives (SLOs). The output is a clean number: "this system handles X concurrent users / Y requests per second at p95 latency under Z." That number is the foundation for infrastructure sizing, contract commitments, and customer-facing capacity claims.

Capacity testing vs breakpoint testing

Both ramp load past expected peak. The difference is the stopping criterion:

• Capacity testing stops when SLOs are first violated (p95 crosses your threshold, error rate exceeds 0.5%, throughput stops scaling linearly). The output is the highest load that still met SLOs.
• Breakpoint testing continues past SLO violation to find the hard failure point — where the system crashes, errors out completely, or stops accepting requests. The output is the absolute ceiling, often well past acceptable performance.

Capacity = max with SLO compliance. Breakpoint = max before total failure. The gap between the two is your safety margin.

When to run a capacity test

• Infrastructure sizing. Knowing one node's capacity tells you exactly how many nodes you need for target traffic plus margin.
• Contract negotiation. Enterprise sales asks "can this handle 50,000 users?" — capacity testing gives an honest answer.
• SLA commitment. Promising 99.9% availability at a specific load requires evidence the load is within capacity.
• Pre-launch validation. Marketing forecasts 5,000 concurrent users at launch. Capacity testing confirms the system handles it with margin, or flags that 5,000 is past capacity and needs scaling.
• Autoscaling configuration. Per-pod capacity divided by target utilisation gives you the scale-out trigger.

Key capacity-test metrics

1. Maximum sustainable VU count or RPS. The main output. The load level at which SLOs were last satisfied.
2. Margin to breakpoint. Capacity / breakpoint ratio. A capacity at 80% of breakpoint is healthy; capacity at 99% of breakpoint is fragile.
3. Resource utilisation at capacity. CPU, memory, DB connections, thread pool at the capacity number. Tells you which dimension to scale.
4. Time at capacity. Does the system hold the capacity load for the full SLO duration (15 min, 1 hour, 24 hours)? Some systems hit a high VU count briefly but degrade over time at sustained load.

How to run a capacity test

Same scripts as load testing, with a step-ramp that pauses at each level long enough to confirm SLO compliance. In JMeter, use the Stepping Thread Group to hold at each VU level for 5-15 minutes before stepping up. In k6, configure a multi-stage ramping-vus scenario with sustained holds at each step.

Define your SLO threshold first (e.g. "p95 latency under 800 ms, error rate under 0.5%"). The capacity is the highest step at which the SLO held for the full hold duration. Drop one step below for a safety margin.

Run from LoadFocus for distributed capacity testing where load generators in multiple regions test the system's geo-distributed capacity, not just single-region.

For capacity testing that informs board-level capacity commitments, LoadFocus offers load testing services where engineers run the test, document the capacity with infrastructure context, and produce a report suitable for stakeholders.