What Is a Spike Test?

Spike testing vs stress testing

Both push past normal load, but they differ in the axis they attack. A stress test raises the level of load until something gives. A spike test raises the rate of change — the peak may be entirely within capacity, yet arriving in five seconds instead of five minutes is what breaks things.

That distinction matters because the two find different bugs. Stress finds resource ceilings; spike finds everything that assumed it would have time to react.

What actually breaks under a spike

Almost every failure in a spike test is a reaction-time failure somewhere in the stack.

• Autoscaler lag. New instances take a minute or more to boot and pass health checks. The spike is often over before capacity arrives.
• Cold caches. A surge of misses hits the database directly, at exactly the moment it can least afford it.
• Connection pool saturation. Requests queue for a connection, response time climbs, and upstream timeouts start firing.
• Retry storms. Clients time out and retry, which adds load to an already saturated system. This is how a survivable spike becomes an outage.

The drop matters as much as the jump

Half of what a spike test measures happens after the surge ends. A system that survives the peak but never returns to baseline — because queues stay backed up, or because scaled-out instances never scale back in — has still failed the test.

Hold the baseline for several minutes after the drop and compare it against the baseline before the spike. Response time, error rate, and resource use should all return to where they started. When they don’t, you have found a recovery bug, which is usually more valuable than the peak number.