What is Capacity Testing?

What is capacity testing?

Capacity testing finds the highest load a system can carry while still meeting its performance targets, such as a p95 response time or an error rate. You raise the load in steps and stop at the last step where every target held. The result is a concrete number, for example concurrent users or requests per second, that you can use to size servers and plan growth.

How a capacity test works

1. Write the targets first. For example: p95 response time under 800 ms and error rate under 0.5%. These are your service-level objectives (SLOs).
2. Ramp in steps. Start below expected traffic and add load in equal steps, holding each step long enough to read stable numbers (5 to 15 minutes is common).
3. Check every target at every step. The step where a target is first missed ends the test.
4. Read the answer. Capacity is the last step where all targets held. Plan to run below it, with a safety margin.

Example: a checkout API holds its targets at 300, 400 and 500 virtual users, then p95 climbs past the limit at 600. Capacity is 500 users. If you expect 450 at peak, you have little headroom, so scale before the launch, not after it.

Capacity testing vs breakpoint testing

Both push load past expected peak. The difference is when you stop:

• Capacity testing stops when the targets are first violated. The output is the highest load that still met them.
• Breakpoint testing keeps going until the system fails hard. The output is the absolute ceiling, usually well past acceptable performance.

The gap between the two is your safety margin. For the wider picture, see scalability testing, which asks how capacity changes when you add resources, and the blog comparison of load testing vs stress testing.

When to run a capacity test

• Infrastructure sizing. One node's capacity tells you how many nodes you need for target traffic plus margin.
• Before a launch or campaign. Confirm the forecast traffic sits inside capacity, or learn that it does not while there is still time to fix it.
• Autoscaling rules. Per-instance capacity divided by your target utilisation gives a sensible scale-out trigger.
• After big changes. A new database, framework version or cache layer can move capacity in either direction.

What to record at capacity

• Maximum sustainable users or requests per second. The main output.
• Margin to the breakpoint. Capacity at 80% of the breakpoint is comfortable; at 99% it is fragile.
• Resource use at capacity. CPU, memory, database connections and thread pools show which part to scale first.
• Time at capacity. Some systems pass a short hold and then degrade under sustained load. Hold the top step for the full duration your SLO covers, and use a longer soak test for slow leaks.

Common mistakes

• Defining no targets, so "capacity" becomes a feeling instead of a number.
• Stepping too fast. Queues and caches need time to fill, so short holds overstate capacity.
• Testing one endpoint when real traffic is a mix. Use a realistic scenario.
• Reading averages instead of percentiles. See latency for why the average hides slow requests.
• Testing a smaller environment than production and scaling the result by guesswork.

Running it with LoadFocus

Capacity testing uses the same scripts as load testing, with a stepped ramp. JMeter and k6 tests can both be run from the cloud, and LoadFocus load testing runs from 25 cloud regions, so you can test capacity as users in several regions would experience it. You can set pass/fail thresholds on p95 and p99 response time, maximum error rate and minimum throughput, and every run gets a pass or fail verdict that can block a deploy from CI. The Free plan is limited to 10 virtual users; paid plans go up to 20,000 concurrent users per test.

FAQ

What is the difference between capacity testing and load testing?

Load testing checks behaviour at an expected load. Capacity testing keeps raising the load to find the maximum the system can sustain within its targets.

How is capacity different from the breakpoint?

Capacity is the last load level that still met your targets. The breakpoint is where the system actually fails. Capacity is always lower, and the gap is your safety margin.

How long should each step hold?

Long enough for response times to settle, commonly 5 to 15 minutes. Systems with caches, queues or connection pools need longer holds to show their real behaviour.

Which metrics define capacity?

Response time percentiles (p95 or p99), error rate and throughput. Capacity is the highest load at which all of them stay inside the targets you wrote down.

How often should I repeat a capacity test?

After significant changes to code, infrastructure or data volume, and before expected traffic peaks. A scheduled run catches slow regressions between those events.