What is Spike Testing in Performance Testing?

Key takeaways

Spike testing applies traffic suddenly rather than ramping, which is what breaks autoscaling and cold caches.
The recovery is half the test. How quickly the system returns to normal matters as much as whether it survived.
Marketing sends spikes, not ramps, so this is the test that matches an email campaign or a launch.

Spike testing is a type of performance testing that raises the load suddenly and sharply, holds it for a short time, then drops it back, to check whether the system survives the surge and returns to normal afterwards. The ISTQB performance testing syllabus defines it as testing “the ability of a system to respond correctly to sudden bursts of peak loads and return afterwards to a steady state”. It is the test that matches a newsletter send, a product launch or a sale opening at a fixed time.

The quick answer

Spike testing applies a sharp, sudden increase in load, holds it briefly, then drops back. It is not about the maximum number of users. A system can pass a stress test at a higher level and still fail a spike at a lower one, because the failure comes from the rate of change rather than the volume.

What is spike testing in software testing?

A spike test compresses the arrival of traffic. Where a load test ramps up over several minutes and lets everything warm up, a spike test puts the extra load on within seconds or a minute and watches what happens in the window before the system has adjusted.

That window is where several things go wrong at once, and none of them appear in a gradual test. The Grafana k6 guide describes the same shape: a very short or no ramp-up to an extreme load, with no plateau or a very brief one.

What spike testing finds

Autoscaling lag. Scaling reacts to load that has already arrived. New instances take time to start and become healthy, and the spike happens inside that gap.
Cold caches. A gradual ramp warms caches as it goes. A spike arrives with the cache empty, so every request reaches the database at once.
Connection storms. Hundreds of connections requested simultaneously can exhaust a pool that copes fine with the same number acquired gradually.
Queue backlog. Work queued faster than it drains, with the backlog outliving the spike itself.
Retry amplification. Clients that time out and retry turn one spike into a larger second one, which is how a brief event becomes a sustained outage.

Spike testing vs load testing vs stress testing

All three put traffic on the same system with the same scripts. What differs is the shape of the load and the question.

	Load testing	Stress testing	Spike testing
Load shape	Ramp to the expected level, hold	Keep climbing past the expected peak	Jump suddenly, hold briefly, drop back
Question	Do we meet our targets at expected traffic?	Where does it break, and how?	Does it survive a burst and recover?
Main result	Percentiles and error rate at target	The breaking point and failure mode	Errors during the burst and time to recovery

Stress testing increases load gradually to find the breaking point, so autoscaling and caches get time to react at every step. Spike testing gives them no time. The two can produce completely different results on the same system, and a team that has run only one of them has an incomplete picture of what a launch will do. A long run at normal load is a third, separate question, covered by soak testing.

How to design a spike test

Decide three things: the baseline before the spike, the height and the duration.

Start from realistic normal traffic rather than from zero, because a system idling at zero has different cache and connection state than one already serving. Set the height from something real: your list size and expected open rate for a campaign, or observed traffic from the last comparable event (our post on whether an email campaign will bring your website down covers sizing the test from your list and open rate). Keep the spike short, because sustaining it turns the test into a load test.

Then hold the baseline again afterwards. That tail is the part people leave out, and it is where recovery is measured.

A spike testing example

Suppose, as an illustration, a shop’s analytics show about 20 page requests per second on a normal afternoon, and the last newsletter pushed traffic to roughly ten times that within a minute of sending. A spike test for the next campaign could look like this:

Baseline: 20 requests per second for 5 minutes, so caches and connection pools are in their normal state.
Spike: climb to 200 requests per second in 30 seconds.
Peak: hold 200 requests per second for 2 minutes.
Drop: return to 20 requests per second within 30 seconds.
Recovery: hold the baseline for 10 minutes and record how long response times and error rate take to return to their step 1 values.

The pass criteria come from your own targets, for example fewer than 1% failed requests during the peak and p95 response time back to its baseline value within a few minutes of the drop.

How to run a spike test in k6

The k6 script below runs that example. It uses the ramping-arrival-rate executor, which starts iterations at the rate you set and adds virtual users (up to maxVUs) when responses slow down. That matters for a spike: with a fixed pool of virtual users, each user waits for its response before sending again, so a struggling server receives fewer requests and the spike quietly softens itself. Real visitors from a newsletter keep arriving whether the site is slow or not.

import http from 'k6/http';

export const options = {
  scenarios: {
    spike: {
      executor: 'ramping-arrival-rate',
      startRate: 20,
      timeUnit: '1s',
      preAllocatedVUs: 100,
      maxVUs: 2000,
      stages: [
        { target: 20, duration: '5m' },   // baseline
        { target: 200, duration: '30s' }, // spike
        { target: 200, duration: '2m' },  // short peak
        { target: 20, duration: '30s' },  // drop back
        { target: 20, duration: '10m' },  // recovery window
      ],
    },
  },
  thresholds: {
    http_req_failed: ['rate<0.01'],
    http_req_duration: ['p(95)<2000'],
  },
};

export default function () {
  http.get(`${__ENV.BASE_URL}/`);
}

Each iteration sends one request, so the stage targets read directly as requests per second. If maxVUs is too low to hold the rate, k6 reports dropped iterations, which means the load generator, not the server, capped the test. To model a VU count instead (a closed model), use the ramping-vus executor with the same stages; the k6 spike testing guide does this, ramping to 2,000 VUs in 2 minutes and back to zero in 1.

How to do spike testing in JMeter

JMeter offers three ways to shape a spike:

Ultimate Thread Group (JMeter Plugins). Each row starts its own set of threads with an initial delay, startup time, hold time and shutdown time. For the example above in VU terms: row 1 runs 50 threads (delay 0 s, startup 60 s, hold 1,080 s, shutdown 10 s) as the baseline, and row 2 adds 450 threads after 360 s (startup 15 s, hold 120 s, shutdown 15 s) as the spike. Row 1 keeps running for about 10 minutes after row 2 ends, which is the recovery window.
Open Model Thread Group (built in since JMeter 5.5, still marked experimental). It schedules arrivals per second, so it behaves like the k6 script above: rate(5/sec) random_arrivals(5 min) random_arrivals(15 sec) rate(50/sec) random_arrivals(2 min) random_arrivals(15 sec) rate(5/sec) random_arrivals(10 min) holds 5 per second, climbs to 50 per second in 15 seconds, holds for 2 minutes, drops back and holds 5 per second for 10 minutes.
Synchronizing Timer (built in). It blocks threads until a set number are waiting, then releases them all at once. Use it for an instant burst on one request, such as everyone pressing “buy” the second a sale opens.

A standard Thread Group with a Ramp-Up Period of 0 also starts every thread at once, but it spikes from zero with no baseline before or after, so it misses the recovery half of the test.

Spike testing with LoadFocus

LoadFocus runs JMeter plans and k6 scripts from 25 cloud regions, so a spike much larger than one machine can generate needs no load generators of your own. k6 scripts run with their scenarios and thresholds, and JMeter plans run with their thread groups, timers and plugins as they do locally. The results charts show when errors appeared and how many virtual users were running at that moment, which is the view you need to read a spike, and each run can be compared with earlier ones. If you would rather have engineers design and run the spike test, LoadFocus also offers load testing services.

Reading the result

During the spike

Elevated response times are expected. What matters is whether requests are served slowly or rejected, and whether errors are clean and bounded rather than cascading into dependencies.

After the spike

Time to recovery is the number worth recording. Compare it with how long your users and your SLOs can tolerate degraded service. A system that stays degraded long after the load has dropped is telling you about a backlog or a resource it did not release, and that is the more serious finding.

The second spike

Running two spikes in the same test is a useful variation. If the second is noticeably worse than the first, something did not recover between them.

Frequently Asked Questions

What is spike testing in performance testing?

Spike testing raises the load on a system suddenly, holds it briefly and drops it back, to check that the system survives the burst and returns to a steady state afterwards. It targets the failures a gradual ramp hides: autoscaling lag, cold caches, connection storms and queue backlogs.

How is a spike test different from a stress test?

Stress testing ramps up to find a limit. Spike testing applies load suddenly to test the reaction to the rate of change. A system can pass one and fail the other.

What is the difference between spike testing and load testing?

A load test ramps to the traffic you expect and holds it long enough to measure steady performance. A spike test jumps to a much higher level within seconds or a minute, holds it briefly and drops back, and its main result is how the system copes with the jump and how fast it recovers.

What is an example of spike testing?

Simulating a newsletter send: a baseline of normal traffic for a few minutes, a jump to about ten times that within 30 seconds, a two-minute peak, then a return to the baseline for ten minutes while you record errors and the time response times take to recover.

How do you do spike testing in JMeter?

Use the Ultimate Thread Group plugin with one row for the baseline threads and a second row that adds the spike threads after a delay with a short startup time, or the built-in Open Model Thread Group with a schedule that jumps from a low arrival rate to a high one. The Synchronizing Timer releases a group of threads at the same instant for a burst on one request.

How big should the spike be?

Set it from something observed rather than a round number: the traffic your last campaign or launch produced, or the peak your list size and open rate imply. An arbitrary multiple tests an event that will not happen.

What should I watch after the spike ends?

Time to recovery. Queue depth, connection pool usage and error rate returning to baseline are what tell you the system released what it acquired, and that is often where the real problem is.

Sources

ISTQB, Certified Tester Performance Testing syllabus v1.0, section 1.2 (spike testing definition), read October 2026.
Grafana k6 documentation: Spike testing (grafana.com/docs/k6/latest/testing-guides/test-types/spike-testing), Ramping arrival rate (grafana.com/docs/k6/latest/using-k6/scenarios/executors/ramping-arrival-rate) and Open and closed models (grafana.com/docs/k6/latest/using-k6/scenarios/concepts/open-vs-closed), read October 2026.
Apache JMeter component reference (Open Model Thread Group, Synchronizing Timer, Thread Group ramp-up) and JMeter Plugins Ultimate Thread Group, read October 2026.