Stress test
Pushing a system beyond expected traffic to find its breaking point, see how it fails, and prove it recovers afterward.
See it
What it is
A stress test drives a system beyond its expected capacity to find the point where service degrades, observe how it fails, and check whether it recovers after pressure drops. Unlike a load test, which asks if targets hold at expected traffic, a stress test keeps climbing past that traffic on purpose. k6, Gatling, Locust, and JMeter can all drive the load.
Reach for one when you need capacity limits, autoscaling behavior, admission-control evidence, or confidence that overload will produce timeouts and backpressure instead of corrupted data. Watch latency and errors beside CPU, memory, database connections, queue depth, restarts, and the time required to return to normal.
Gotcha: the load generator can fail before the target does, and an unbounded test can damage shared environments. Set a ceiling and abort conditions, isolate test data, and coordinate with operators. A clean recovery matters as much as the breaking point: capacity that returns only after a manual restart is a different result.
Ask AI for it
Write a k6 stress test using the ramping-vus executor. Warm up at 50 VUs, then increase through 100, 200, 400, and 800 VUs in fixed stages, hold each stage long enough to stabilize, and ramp back to 50 for a recovery window. Record RPS, p95 and p99 http_req_duration, http_req_failed, CPU, memory, database pool saturation, and queue depth. Add safety abort conditions, identify the first breached service-level target, and fail recovery if metrics do not return near the warm-up baseline without a restart.