Pass/Fail Thresholds

Pass/fail thresholds set the limits a load test must stay within, for example a maximum response time. You set them once on a test, and every run is graded automatically: a green PASS or a red FAIL, with each limit compared against the run's real numbers. Thresholds work the same way for cloud, JMeter and k6 tests.

Set your thresholds

On the new-test page, open More options, click the Pass/fail checks row and fill in any of:

Max P95 response time (ms): the run fails if the 95th-percentile response time is above this.
Max P99 response time (ms): same, for the 99th percentile.
Max error rate (%): the run fails if the overall error rate is above this.
Min throughput (req/s): the run fails if throughput is below this.

Leave a field empty to skip that check. Tick Enable pass/fail thresholds to turn the verdict on. Thresholds are saved per test and per team, so you set them once and they apply to every future run.

Two optional fields compare a run with the run you marked as baseline on its results page: Max P95 rise vs baseline and Max error rate rise vs baseline (points). Until a baseline is set these checks are skipped, so a gate that has only these limits fails as "not evaluated".

Read the verdict

Open any result for a test that has thresholds enabled. The overview shows a PASS or FAIL badge with a line per check: the actual value, the target, and whether it passed. The badge is evaluated against the same overall numbers shown on the results page.

Watch trends across runs

The Trend tab plots P95 response time, error rate and throughput across the recent runs of the test, with your thresholds drawn in as lines and each run coloured green (pass) or red (fail). It builds itself from your run history, so a creeping regression is easy to spot.

Gate your CI/CD pipeline

The verdict is also available to automation, so a load test can block a bad deploy:

GitHub Action: the LoadFocus load-test gate action runs a test, waits for it to finish, reads the verdict, and exits non-zero when a threshold is breached or cannot be evaluated (which fails the workflow step).
Verdict API: GET /api/v1/{loadtests|k6tests|jmetertests}/verdict?testrunname=<name>&testrunid=<id> (with your loadfocus-auth API key) returns { verdict, checks, metrics, ... } so any pipeline can gate on the result. Call it on a finished run.
Thresholds API: set or update a test's limits from a pipeline (SLOs as code) with PUT /api/v1/{loadtests|k6tests|jmetertests}/thresholds (JSON body { "testrunname": "...", "p95Ms": 500, "errorRatePct": 1, "minRps": 50 }, with your loadfocus-auth API key; p99Ms and enabled are also accepted). A PUT replaces the whole set, so a field you leave out is cleared. GET the same path reads them, DELETE clears them.
Analysis API: GET /api/v1/{loadtests|k6tests|jmetertests}/analysis?testrunname=<name>&testrunid=<id> returns the numbers behind the verdict as JSON (exact percentiles, Apdex, error types, per-request and per-region metrics). See Results Analysis API.

Get alerted if a run doesn't finish

If a run hangs and never finishes, LoadFocus emails the team owner automatically, so a stuck run never goes unnoticed.