---
title: "The value of stress testing | Grafana Labs"
description: "Learn why stress testing reveals degradation patterns that baseline tests cannot."
---

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

# The value of stress testing

A baseline test tells you whether your system meets its SLOs under realistic load. Stress testing answers a different question: what happens when load is **heavier than usual**, beyond the levels you validated in baseline testing? A stress test explores how performance **degrades** under that overload and whether the system **survives** it.

The exercises on this path use **2× and 3×** your baseline VU targets as a concrete teaching example; official guidance does not prescribe a fixed multiplier. Refer to [Stress testing](/docs/k6/latest/testing-guides/test-types/stress-testing/) for how load should relate to average traffic and when to run stress tests after baseline. The goal is to see **how much** performance slips, **where** strain first appears, and whether the system stays within acceptable failure bounds.

Stress testing can reveal degradation patterns that baseline tests do not surface:

- **Gradual degradation**: Latency climbs steadily as load increases, but the system continues to respond. This shows where performance starts to suffer and how gracefully your system handles overload.
- **Sudden failure**: The system performs well until a specific load level, then error rates jump sharply within a single stage. This pattern often points to a hard resource limit, such as connection pool exhaustion or memory pressure.
- **Cascading failure**: One component fails under stress, which causes dependent components to fail. Response times for unrelated endpoints can spike because a shared resource is saturated.

Understanding these patterns helps you make informed decisions about capacity planning, autoscaling triggers, and alert thresholds. Without stress testing, you are operating on assumptions about what your system can handle under surge conditions such as paydays, rush hours, or deadline-driven traffic spikes.

Run stress tests only after average-load or baseline tests pass, as recommended in [Stress testing](/docs/k6/latest/testing-guides/test-types/stress-testing/). Expect worse performance than at baseline: the test determines how much performance degrades with the extra load and whether the system survives it.

In the next milestone, you design a stress profile that pushes your system beyond its normal operating range.