Run the spike test and interpret results

Running the spike test reveals how your system responds to a sudden burst. The test is shorter than a baseline or stress test (about seven minutes), but the summary packs the baseline phase, the spike, and the recovery into a single set of aggregated metrics. Compare these values against your baseline results to determine whether the spike had an effect.

To run the spike test and interpret the results, complete the following steps:

1. Open your terminal and run the spike test:

   Bash Copy

   k6 run spike.js

   As the test runs, watch the real-time VU count. You’ll see it hold at 5, then jump to 100 within seconds, hold, and drop back to 5. The sharp transitions are visible in the progress output.

   Tip

   To watch the spike unfold on a live chart instead of reading terminal output, enable the built-in web dashboard: run K6_WEB_DASHBOARD=true k6 run spike.js and open http://127.0.0.1:5665 in your browser. Refer to Web dashboard.

2. When the test completes, review the summary. At the top, find █ THRESHOLDS and confirm each threshold from spike.js passed or failed:

   text Copy

     █ THRESHOLDS
   
       http_req_duration
       ✓ 'p(95)<1500' p(95)=55ms
   
       http_req_failed
       ✓ 'rate<0.10' rate=0.00%

   A ✓ means the threshold passed. A ✗ means it failed and k6 exits with a non-zero exit code (typically 99). Your exact values differ from this example; compare them against your baseline results.

3. Under █ TOTAL RESULTS, find the checks and HTTP metrics. Compare each value against your baseline test results:

   Checks (confirm correctness held; checks_failed should show 0 out of the same total as checks_succeeded):

   text Copy

     █ TOTAL RESULTS
   
       checks_total.......................: 6400    15.2/s
       checks_succeeded...................: 100.00% 6400 out of 6400
       checks_failed......................: 0.00%   0 out of 6400
   
       ✓ status is 200
       ✓ response body is not empty

   http_req_duration under HTTP (compare p95 and max):

   text Copy

       HTTP
       http_req_duration..................: avg=42ms    min=30ms    med=40ms    max=620ms    p(90)=48ms     p(95)=55ms
         { expected_response:true }.......: avg=42ms    min=30ms    med=40ms    max=620ms    p(90)=48ms     p(95)=55ms
       http_req_failed....................: 0.00%  0 out of 3200
       http_reqs..........................: 3200   7.5/s

   A higher max than your baseline, or a non-zero http_req_failed rate, suggests the burst had an effect even when thresholds pass.

4. Record the differences between your spike and baseline values for p95 latency, max latency, error rate, and check pass rate.

   For now, a scratch note is enough; the Document spike results and measure recovery milestone walks you through a structured, per-phase results table.

   Because the summary aggregates all phases, even small differences from your baseline indicate the spike had an effect.

   Note

   The end-of-test summary blends all phases into a single set of metrics. To see how metrics changed over time during the burst compared to recovery, you need a timeline view. In the next milestone, you send results to Grafana Cloud k6 to get that visibility.

In the next milestone, you visualize the spike test in Grafana Cloud k6 to see how metrics correlated with each phase of the test.