Document spike results and measure recovery

The Grafana Cloud k6 timeline shows what happened during the spike. Record baseline, spike, and recovery metrics so you can compare runs, track changes over time, and share results with your team.

Recovery time and the fast, slow, and no-recovery categories in this milestone are teaching heuristics, not k6 defaults. Adapt the 10% baseline band and time buckets (30 seconds, 3 minutes) to match your SLOs and how your team defines acceptable recovery.

To document your spike results and measure recovery, complete the following steps:

1. Open your spike test result in Grafana Cloud k6.

   Use the Performance Overview timeline to identify three points in time:

   • Baseline end: The last moment before VUs begin to climb (around the 2-minute mark in the test profile from the previous milestones).
   • Spike peak: The point where VUs reach 100 and response time is at its highest.
   • Recovery point: The first moment after the spike where response time returns to within 10% of the baseline value. If response time never returns to baseline before the test ends, note the value at the end of the observation period.

   Hover over the response time series on the Performance Overview timeline at each phase to read the values.

2. Record the per-phase metrics from the timeline.

   You can use a table in a shared document, a spreadsheet, or whatever format your team uses:

   Expand table

   Metric	Baseline	Spike peak	Recovery point
   Response time (ms)
   Request rate (req/s)
   Failure rate (%)
   Active VUs	5	100	5

   The baseline values serve as your reference point for all comparisons.

3. Click the HTTP tab to see p95 and p99 latency percentiles for each URL in your test.

   Each row is one request group. With the single-URL spike.js from earlier milestones, one row covers the whole run. Those percentiles blend all phases together, so they won’t show per-phase p95. Use them to compare against your baseline test’s p95 and to track changes across runs.

4. Click the Thresholds tab to confirm whether your p95 threshold (p(95)<1500) passed or failed.

   If it passed despite the spike, your system stayed within the allowed latency envelope even under burst conditions.

5. Calculate your recovery time.

   Find the timestamp where VUs dropped back to 5 and the timestamp where response time on the timeline returned to within 10% of its baseline value. The difference between these two timestamps is your recovery time.

   Categorize the result:

   • Fast recovery (under 30 seconds): The system handled the spike without lasting impact. Resources released quickly and request queues drained immediately.
   • Slow recovery (30 seconds to 3 minutes): The system remained operational during the burst but needed time to process the backlog. This is common when connection pools, downstream services, or caches need time to replenish.
   • No recovery: Latency or error rates remained elevated through the end of the observation period. The system did not return to baseline before the test ended, which suggests a lasting disruption from the spike.

6. If the system showed fast recovery with no visible degradation, run the test again with a higher spike multiplier.

   Increase the spike target from 100 to 200 or 500 VUs while keeping the baseline at 5 VUs. This finds the point where the system’s burst capacity is actually challenged.

   Note

   At these higher VU counts, running with --local-execution can make your own machine the bottleneck, which skews the results. Generate the load in the cloud instead by running k6 cloud run spike.js (without the --local-execution flag).

   Compare the results side by side. Grafana Cloud k6 lets you compare two test runs directly, which makes it easy to see how the system’s response changed as you increased the spike intensity.

   Tip

   If you run multiple spike tests with increasing multipliers, keep your results table consistent across runs. Label each row with the multiplier (20x, 40x, 100x) so you can see the progression from “handles easily” to “starts degrading” to “overwhelmed.”

7. Save your documented results.

   You’ll reference these measurements in a later milestone when you turn them into follow-up actions.

In the next milestone (optional), you extend the spike to multiple endpoints and compare routes, then (optionally) add authentication. To skip the optional milestones and go straight to Turn spike results into action, open that milestone in the sidebar.