---
title: "Run the breakpoint test and identify the ceiling | Grafana Labs"
description: "Run the breakpoint test and identify the capacity ceiling where thresholds stop the run."
---

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

# 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 code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy
   
   ```bash
   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](/docs/k6/latest/results-output/end-of-test/) and [`--summary-mode`](/docs/k6/latest/using-k6/k6-options/reference/#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 code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy
   
   ```text
   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 code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy
   
   ```text
   █ 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.