Failure breakdown, by cause
Validation & CIWhen things break, loadr buckets failures by cause — transport errors, timeouts, bad statuses, failed checks — so you see why the run went red, not just that it did.
Browse all 52 demos 12 categories
No demos match.
$ loadr run examples/26-failure-breakdown.yaml
# Deliberately produces a MIX of failures so the web UI's failure breakdown
# panel has something to group: a healthy endpoint, 4xx and 5xx responses, a
# check that fails, and a JS step that throws an uncaught exception.
#
# Run it with the management UI and watch the "Failure breakdown" panel:
#
# docker compose -f examples/harness/docker-compose.yml up -d --build
# loadr run --ui examples/26-failure-breakdown.yaml
#
# (go-httpbin's /status/{code} endpoint returns the requested status code.)
name: failure-breakdown
description: a mix of 4xx/5xx, a failing check, and a script exception
defaults:
http:
base_url: http://127.0.0.1:8080
timeout: 10s
js:
file: scripts/failure-breakdown.js
scenarios:
mixed:
executor: constant-vus
vus: 8
duration: 40s
exec: maybeThrow # ~1 in 4 iterations throws an exception
flow:
# Healthy traffic — the baseline.
- request:
name: ok
method: GET
url: /status/200
checks:
- { type: status, equals: 200 }
# Server errors (500) — counts under "HTTP status".
- request:
name: server-error
method: GET
url: /status/500
# Client errors (404) plus a check that fails on them — the check failure
# shows up under "Failed checks", the 404 under "HTTP status".
- request:
name: not-found
method: GET
url: /status/404
checks:
- { type: status, name: resource exists, equals: 200 }
# A 503 to add a second 5xx bucket.
- request:
name: unavailable
method: GET
url: /status/503
thresholds:
http_req_failed: [ "rate<0.5" ]
checks: [ "rate>0.5" ]View raw: examples/26-failure-breakdown.yaml
Related files: scripts/failure-breakdown.js
What it shows
- ▸Failures grouped by normalized cause
- ▸Separates transport vs assertion failures
- ▸Feeds the HTML report's breakdown