---
title: "Document the stress result | Grafana Labs"
description: "Document the stress result, including degradation thresholds and capacity notes."
---

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

# Document the stress result

You identified failure signals, or confirmed a clean run, in the previous milestone. Capture those metrics while they are fresh. Whether degradation appeared or the system stayed healthy at 2× and 3× load, written results become reference points for capacity planning and future comparisons.

For single-request scripts like this path, use the per-second rate on the **`http_reqs`** line in compact summary output (for example `7.5/s`) as your throughput figure. If the rates on **`iterations`** and **`http_reqs`** diverge, trust **`http_reqs`** for request throughput. Refer to [Metrics](/docs/k6/latest/using-k6/metrics/).

To document your stress result, complete the following steps:

1. Record your key stress metrics in a table.
   
   Pull values from [Run the stress test](/docs/learning-paths/find-k6-limits/run-stress-test/) and organize them by load stage.
   
   **Note:** The end-of-test summary aggregates metrics across the entire run. To fill per-stage columns, watch real-time output during the test, or send results to [Grafana Cloud k6](/docs/grafana-cloud/testing/k6/) where you can correlate metrics with VU stages on a timeline.
   
   Expand table
   
   | Metric           | Baseline (20 VUs) | Mid stress (40 VUs) | Max stress (60 VUs) |
   |------------------|-------------------|---------------------|---------------------|
   | p95 latency      | *your value*      | *your value*        | *your value*        |
   | Error rate       | *your value*      | *your value*        | *your value*        |
   | Throughput (RPS) | *your value*      | *your value*        | *your value*        |
   | Checks pass rate | *your value*      | *your value*        | *your value*        |
   
   **Example when degradation appears:**
   
   Expand table
   
   | Metric           | Baseline (20 VUs) | At degradation (40 VUs) | At max load (60 VUs) |
   |------------------|-------------------|-------------------------|----------------------|
   | p95 latency      | 350 ms            | 1200 ms                 | 2100 ms              |
   | Error rate       | 0%                | 3.4%                    | 12.8%                |
   | Throughput (RPS) | 10                | 15                      | 14                   |
   | Checks pass rate | 100%              | 94.2%                   | 85.1%                |
   
   Throughput can plateau or drop at the highest stage when the system is overwhelmed: resources go to retries and error handling instead of successful requests.
   
   **Example when all stages stayed healthy (common on QuickPizza):**
   
   Expand table
   
   | Metric           | Baseline (20 VUs) | At 2x load (40 VUs) | At 3x load (60 VUs) |
   |------------------|-------------------|---------------------|---------------------|
   | p95 latency      | 280 ms            | 290 ms              | 310 ms              |
   | Error rate       | 0%                | 0%                  | 0%                  |
   | Throughput (RPS) | 10                | 20                  | 30                  |
   | Checks pass rate | 100%              | 100%                | 100%                |
   
   This result means the system comfortably handled 3x your baseline load within the test parameters. Record it even when no degradation threshold appears.
2. Record your degradation threshold.
   
   If errors, latency, or check failures first moved beyond acceptable levels at a specific stage, note that **VU count** and the **`http_reqs`** rate (requests per second) at that stage. For example, if strain first appeared at 40 VUs and ~15 RPS, record both values.
   
   If all stages stayed healthy, note **no degradation threshold within test parameters**, a valid outcome on resilient targets such as QuickPizza.
   
   **Tip:** Run the stress test two or three times to confirm results. A single run can reflect network noise or background load; consistent numbers across runs increase confidence in your threshold.
3. Optional: store the run in k6 Cloud for history:
   
   Bash ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy
   
   ```bash
   k6 cloud run --local-execution stress.js
   ```

You can stop here if you only needed the stress workflow. When you are ready to search for an outer bound on a dedicated stack, the next milestone walks you through building a breakpoint script.