What Is a Stress Test?

Stress testing vs load testing

A load test asks whether the system meets its targets at expected load. A stress test asks what happens when it doesn’t. The difference is intent: a load test is a pass-or-fail check against a known number, while a stress test is an exploration of the region past that number, where the answer is not known in advance.

That makes a failed stress test a successful one. If load rises until something breaks and you learn which component gave way and how, the run did its job. A stress test that stays green has usually just not pushed hard enough.

What a stress test reveals

Three findings matter more than the peak number itself, and none of them appear in a test that stops at expected load.

• The first bottleneck. Something always saturates first — CPU, a connection pool, a downstream quota. Knowing which one tells you what to fix.
• The failure mode. Graceful degradation (slower responses, shed load, queued work) is survivable. A cliff — cascading timeouts, retry storms, OOM kills — is not.
• Recovery. Whether removing the load restores service, or whether the system stays down until it is restarted. This is the difference between a bad ten minutes and a bad afternoon.

Running one without causing an incident

A stress test is designed to break something, so decide in advance what it is allowed to break. Run against an environment you can afford to lose, and check what shares infrastructure with it — a staging database on the same instance as production is the classic way a stress test becomes an outage.

Watch third-party dependencies especially closely. Payment gateways, email providers, and SMS APIs are rate-limited and often billed per call, and driving them past expected load can cost money or get an account suspended. Stub them, or point the test at their sandbox.