The value of spike testing

A baseline test tells you whether your system meets its service-level objectives (SLOs) under steady load. An SLO is a target you set for a reliability metric, such as “99.9% of requests succeed” or “p95 latency stays under 500 ms”; to build one, see Create an availability SLO. Spike testing answers a different question: what happens when traffic jumps sharply in seconds, and how quickly do latency and errors return to normal afterward? Sudden surges from launches, campaigns, or redirected traffic are common reasons to run a spike test.

Spike testing can reveal burst and recovery patterns that gradual ramps miss:

• Burst response: When traffic jumps from baseline to 10x or 20x in seconds, a spike test shows whether latency rises, the system returns 429 (Too Many Requests) or 503 (Service Unavailable) responses under pressure, or errors and latency climb together.
• Recovery time: After the burst ends, compare how long latency and error rates take to return to baseline. A system that recovers in seconds differs from one that stays degraded while queues drain or downstream services catch up.
• Instant load changes: Baseline and stress tests ramp load gradually. Spike tests use ramps measured in seconds, so issues that only appear when load changes instantly may not show up in those test types.

In the next milestone, you design a spike profile with sharp stage transitions that simulate a sudden traffic burst and a recovery observation period.