Run the breakpoint test and identify the ceiling

The breakpoint test ramps load continuously until abortOnFail thresholds stop the test (or you stop it manually). The run often ends while the script still schedules more load. You are measuring where the system fails your conditions, not necessarily where hardware or the process dies. When the test aborts, the final metrics give an approximate ceiling under this script and threshold set: the request rate and concurrency in the summary at the stop point.

To run the breakpoint test and identify the ceiling, complete the following steps:

1. Open your terminal and run the breakpoint test:

   Bash Copy

   k6 run breakpoint.js

   Watch the real-time output. Unlike the stress test with its discrete stages, you’ll see a steady, continuous increase in request rate. The VU count and iteration rate climb gradually until thresholds fail or the scheduled ramp ends.

   The end-of-test block uses compact summary mode by default from k6 v1.0.0 (see End of test and --summary-mode). Compact mode lists THRESHOLDS first, then TOTAL RESULTS with HTTP and EXECUTION subsections. The excerpt in step 3 matches that layout, not --summary-mode=legacy.

2. Wait for the test to abort.

   When a threshold with abortOnFail is evaluated as failed, k6 stops the test (after any delayAbortEval delay used for threshold evaluation). You should see a message like:

   text Copy

   threshold 'http_req_failed{rate<0.20}' has been crossed, aborting test run

   If the test completes without aborting, the system handled the full load ramp without crossing the failure thresholds. This is common when testing against resilient services like QuickPizza. If you’re testing your own service, increase the target value in your breakpoint script and run again. If you’re using QuickPizza, proceed to the next step using the final summary output. The methodology is the same regardless of whether the test aborted.

3. In the end-of-test summary, read iteration throughput, VU headroom, and HTTP health at abort or at normal completion.

   Under EXECUTION, find iterations (per-second rate is completed iterations per second) and vus_max. Under HTTP, find http_req_failed and http_req_duration (one line with all trend stats). If your script issues multiple HTTP calls per iteration, prefer http_reqs per second for request throughput. For example:

   text Copy

   █ THRESHOLDS
   
   http_req_duration
   ✗ 'p(95)<2000' p(95)=8100ms
   
   http_req_failed
   ✗ 'rate<0.20' rate=24.31%
   
   █ TOTAL RESULTS
   
   HTTP
   http_req_duration..................: avg=2400ms   min=92ms     med=1800ms   max=30000ms  p(90)=5200ms  p(95)=8100ms
   http_req_failed....................: 24.31%  4509 out of 18542
   
   EXECUTION
   iterations.........................: 18542  72.35/s
   vus_max............................: 487    min=20      max=487

   Here the run was near 72 completed iterations per second when it stopped, with p95 latency at 8100 ms and a high http_req_failed rate, patterns you would read alongside the threshold abort message from step 2.

4. Record the ceiling values.

   The numbers from the abort (or from normal completion if thresholds never failed) describe load at the stop point for this ramp and these thresholds, not a universal mathematical maximum. Use a table like this:

   Expand table

   Metric	Value at test stop
   Request rate (RPS)	~72
   Active VUs	487
   p95 latency	8100 ms
   Error rate	24.3%

   Note: The breakpoint ceiling is not an operating target: it is where your thresholds ended the run. Plan day-to-day capacity below this number. If stress found a degradation threshold, use that as the practical limit and treat breakpoint values as an outer bound. On QuickPizza, a full ramp without abort is valid; record final metrics instead.

You can now record load at test stop from the compact summary, whether the run aborted on thresholds or completed the full ramp.

In the next milestone, you bring together your stress and breakpoint results to understand the full capacity picture of your system.