--- title: "Turn spike results into action | Grafana Labs" description: "Map your spike test response pattern to follow-up actions, connect recovery time to your SLOs, and plan when to run spike tests again." --- > For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt). # Turn spike results into action 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. Expand table | 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. Expand table | 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. Expand table | 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. Expand table | 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. Expand table | 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. Expand table | 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.