Stress testing

Stress testing deliberately drives a system past its expected load, step by step, until it stops meeting its targets or fails outright. Where a load test asks “do we cope with normal peak?”, a stress test asks “how much can we take, what breaks first, and what happens to users when it does?”

Example (k6 ramping arrival rate)

Increasing the request rate in steps, independent of how fast the server responds:

import http from 'k6/http';

export const options = {
  scenarios: {
    breakpoint: {
      executor: 'ramping-arrival-rate',
      startRate: 50,
      timeUnit: '1s',
      preAllocatedVUs: 200,
      maxVUs: 2000,
      stages: [
        { duration: '5m', target: 200 },
        { duration: '5m', target: 400 },
        { duration: '5m', target: 800 },
        { duration: '3m', target: 0 }, // ramp down to observe recovery
      ],
    },
  },
};

export default function () {
  http.get('https://staging.example.com/api/search?q=shoes');
}

An arrival-rate executor keeps sending requests at the target rate even when responses slow down, which is closer to real users and exposes saturation more clearly than a fixed number of virtual users.

What to observe

• The knee. The rate at which latency percentiles start climbing sharply while throughput flattens. That is your practical capacity.
• The failure mode. Graceful degradation looks like fast 429 or 503 responses and shed load. Bad failure looks like timeouts, cascading failures in other services, data corruption or crashed processes.
• Recovery. After the ramp-down, does latency return to normal on its own, or do stuck connections and full queues need a restart?
• The first bottleneck. CPU, database connection pool, thread pool, memory or a downstream dependency. Fixing it moves the breaking point, so stress tests are often repeated.

How it differs from spike testing

A stress test ramps up gradually to find a limit. A spike test jumps from normal to very high load almost instantly, for example a flash sale or a push notification, and checks whether autoscaling and queues react fast enough.

Common mistakes

Running stress tests against shared environments other teams depend on, running them from a single load generator that saturates before the server does, and stopping at “it broke at 800 rps” without recording how it broke and whether it recovered.