---
title: "Turn soak results into action | Grafana Labs"
description: "Map soak degradation types to investigation areas and build soak testing into your operational cadence."
---

> For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt).

# Turn soak results into action

Use the degradation category from the previous milestone to pick the next investigation. Memory-related drift and connection-pool exhaustion need different follow-up.

To turn your soak results into actions, complete the following steps:

1. Open your documented results and identify which degradation category your test fell into.
   
   **Memory-related degradation**: Latency rose gradually, correlated with increasing memory usage or GC pressure on the system under test.
   
   - Review application-level caching and session storage for unbounded growth.
   - Check for long-lived collections that accumulate per request (logging buffers, metrics registries, listener lists).
   - Set a memory usage alert in Grafana from the drift rate you measured.
   
   **Connection-related degradation**: Latency was stable, then jumped as the connection pool reached capacity.
   
   - Compare pool maximum to sustained request rate.
   - Look for connections not returned on error paths or timeouts.
   - Add a dashboard panel for pool utilization over time.
   
   **Disk-related degradation**: Performance changed when disk space or log volume approached limits.
   
   - Review log rotation and temp-file cleanup.
   - Set disk usage alerts from the fill rate you observed.
   
   **No degradation observed**: Metrics remained stable for the full test duration.
   
   - Extend duration on the middle `stages` entry (for example from 30 minutes to 4 or 8 hours on a production soak).
   - Increase load toward your average-load ceiling if you need more pressure.
   - Keep the clean result as a reference for the next code or infrastructure change.
2. Set duration targets for future soak tests based on what you learned.
   
   On a production soak, if degradation appeared at 90 minutes, the next run should last at least 3 hours to confirm a fix. If no degradation appeared in 2 hours, extend to 4 or 8 hours.
   
   A useful rule: run at least twice as long as the time-to-degradation you observed so a fix is less likely to be a short delay rather than a real resolution.
3. Plan when to run soak tests.
   
   Soak tests cost more time than stress or spike runs, so most teams run them less often:
   
   - **After changes to resource management**: Caching, connection pooling, session handling, or background jobs.
   - **Monthly or before major releases**: Catches slow regressions from small cumulative changes.
   - **After infrastructure changes**: New database instances, memory limits, or disk allocations.

In the next milestone, you review what you accomplished and explore next steps.