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.

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 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 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

   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.