Spike test
A load test that slams the system with a sudden traffic burst, then checks whether it stays useful and returns to normal.
What it is
A spike test jumps from normal traffic to a much larger burst with little or no ramp, holds it briefly, then drops back. It asks two questions a normal load test does not: what happens at the instant demand changes, and does the system recover afterward? Think Ticketmaster's 2022 Eras Tour presale, a push notification landing on a million phones at once, or the old Slashdot effect arriving at your homepage.
Use one to inspect autoscaling lag, rate limits, queue backlogs, cache stampedes, and recovery time. Watch the burst and the quiet period after it, because a service that survives the peak but remains slow for twenty minutes has not recovered cleanly.
Gotcha: generating an instant spike from one laptop can bottleneck the load generator before the system under test. Use distributed generators when needed, protect third-party APIs with fakes or sandboxes, and set hard ceilings so the exercise cannot spill into unrelated production tenants.
Ask AI for it
Write a k6 spike test with a `ramping-vus` scenario: hold 50 VUs for two minutes, jump to 1,000 VUs in 10 seconds, hold for one minute, drop back to 50, and observe recovery for five minutes. Tag metrics by baseline, spike, and recovery phase. Add phase-specific thresholds for `http_req_failed` and p95 `http_req_duration`, record autoscaling events and queue depth in Grafana, and fail the run if recovery metrics do not return to baseline limits within two minutes.