Documentation for automated readers A curated documentation index is available at: https://grafana.com/llms.txt
A complete documentation index is available at: https://grafana.com/llms-full.txt These indexes can help with page discovery before fetching individual documents.
This page is also available in Markdown, which may be easier for automated readers
and AI tools to parse than HTML. The Markdown version is available at
https://grafana.com/docs/learning-paths/k6-spike-testing/act-on-results.md, or by sending
Accept: text/markdown to https://grafana.com/docs/learning-paths/k6-spike-testing/act-on-results/. For broader
documentation discovery, the curated index is available at https://grafana.com/llms.txt
and the complete index is available at https://grafana.com/llms-full.txt.
If you skipped the optional milestones (multiple endpoints or authentication), you still have everything you need: use the measurements and recovery category from Document spike results and measure recovery (and your Grafana Cloud k6 timelines from earlier milestones).
Knowing your recovery time is useful, but only if it leads to a decision. The response pattern you documented in the previous milestone maps directly to specific architectural strategies. A recovery time of 5 seconds calls for a different plan than a recovery time that never arrived.
Note
The tables below summarize follow-up actions by recovery category. Use the category you recorded in the previous milestone and read that section first. The time buckets (30 seconds, 3 minutes) are starting points from that milestone; tune them for your SLOs and traffic patterns.
Pick your recovery category
Use the category you recorded when you measured recovery time.
Recovery category
What it usually means
Your first priority
Fast recovery (under 30 seconds)
Metrics returned to baseline quickly after the burst.
Find where burst capacity starts to break down (higher multiplier, more endpoints).
Slow recovery (30 seconds to 3 minutes)
The system stayed up but needed time to drain backlog or refill pools.
Connection pools, autoscaling timing, and queue depth.
No recovery
Latency or errors did not return to baseline before the test ended.
Resource leaks, downstream failure, and whether you need load shedding.
Follow-up actions by recovery category
The following three sections expand each row of the table above. Read the one that matches the category you recorded.
Fast recovery (under 30 seconds)
Your system handled the spike well at this multiplier. The main question is where degradation begins.
Action
What to do
Raise the load
Double the spike target (for example, from 100 to 200 VUs) and run again. Keep increasing until recovery time starts to grow.
Split by endpoint
Create separate spike tests for endpoints with different profiles (database-heavy routes, uploads, third-party calls). Burst capacity varies by route.
Record the ceiling
Note the highest multiplier where recovery stayed under 30 seconds. Treat that as the current burst boundary for this endpoint and share it with your team.
Slow recovery (30 seconds to 3 minutes)
The system remained operational but recovered gradually. That pattern often points to contention that clears over time. Here are three examples of resource contention that could produce slow recovery — many other causes are possible, so treat this as a starting point rather than a definitive list.
Investigation
What to look for
Connection pools
Whether database or HTTP client pools were sized for bursts or only steady load, and whether the spike exhausted them.
Autoscaling timing
Compare your recovery window to how long new capacity takes to become ready. If instances need 90 seconds but recovery took 2 minutes, the autoscaler may be too slow. Tighter scale-up triggers or pre-warming can help.
Queue depth
Whether request, message, or work queues grew during the spike and how long they took to return toward empty.
No recovery
Latency or error rates did not return to baseline during the observation period. Treat this as the highest-severity outcome: a real spike could cause a lasting outage. Here are three examples of areas you may want to investigate if your system is not recovering — again, these are common starting points, not an exhaustive list.
Investigation
What to look for
Resource leaks
Connections, threads, or memory that are not released after the burst. Compare infra metrics before versus after the spike.
Cascading failures
Whether errors cluster on a specific downstream dependency that never stabilized.
Load shedding
Whether accepting every request during the burst made things worse. Rate limits or circuit breakers that shed excess load early can protect the core path.
Compare recovery to SLOs and alerting
Connect numbers from the spike run to how your team defines good and bad.
Question
Why it matters
Is recovery time acceptable for your SLO and error budget?
A multi-minute degraded window can burn a large share of budget depending on traffic during that window.
Should recovery be its own objective?
Some teams track mean time to recovery (MTTR) separately from availability. Your spike run is a controlled data point for that.
Did alerts fire during the test?
If rules did not fire when you deliberately caused elevated latency, they may not fire in a real incident either.
Plan when to run spike tests again
Repeat spike tests after major changes so results stay current.
When to run
Why
After major deployments
Changes to request paths, queries, or infra can shift burst behavior quickly.
Monthly or quarterly
Dependency updates, data growth, and drift still change systems without a big release.
Before anticipated traffic
Launches, campaigns, or seasonal peaks warrant a rehearsal with a multiplier grounded in projections.
In the next milestone, you review what you’ve accomplished and explore next steps.
More to explore (optional)
At this point in your path, you can explore the following topics:
