Protocol
Find the breaking point before production finds it for you
Capacity is a fact you discover by pressure, not a number you inherit from last year's diagram.
When it fits
- A service, agent workflow or batch process has never been tested beyond its normal load.
When to avoid it
- Do not load-test shared production systems without explicit safety controls and authorization.
Why it matters
Increase representative load in a controlled environment until latency, errors or useful throughput begin to degrade. Record the bottleneck and the failure shape, not only the maximum completed rate. Test both gradual and sudden load where bursts are plausible.
Steps
- The workload resembles real request or job shapes.
- Load increases beyond normal operating level.
- Useful throughput, latency and errors are observed together.
- The first bottleneck and overload failure mode are recorded.
- Recovery after overload is tested, not only the climb.
An example
Run an agent queue past normal parallelism to see whether tool rate limits, memory, retries or human review become the real constraint.
Check your result
The team knows where useful throughput stops scaling and what fails first.
Keep this limit in mind
- Do not load-test shared production systems without explicit safety controls and authorization.
Connected ideas
Use beforeKeep headroom for variability and recoveryUseful with
Let reliability data slow feature velocity when the budget is spent
Evidence and sources
Google SRE recommends load testing capacity limits and overload failure modes because overload can reduce useful throughput rather than merely slow work.
Load-test conditions must resemble the workload enough to expose the real bottleneck.
Addressing Cascading Failures · Preventing server overload and testing for cascading failures