Understanding results
Key metrics
Response time
http_req_durationHow long your server takes to respond. Look at the median (p50) for typical performance and p95/p99 for tail latency.
Throughput
http_reqsRequests per second your server handles. In an arrival-rate run the plan fixes the rate sent, so throughput should track the plan.
Error rate
http_req_failedShare of requests that returned an HTTP error or failed to connect. loadtest.dev splits it into 5xx, 4xx, 429, timeout and transport.
Rate limited
429Responses refused by a rate limiter. On a preview, a signed load run skips the narduk-core limiter, so a 429 there comes from somewhere else. Production keeps its limits, and 429s are reported as their own class.
Check pass rate
checksHow many of your custom checks passed. Checks validate response bodies, headers, and status codes.
Data transfer
data_received / data_sentTotal bytes transferred during the test. Useful for estimating bandwidth costs and spotting payload bloat.
Understanding percentiles
Averages lie. If your average response time is 200ms but your p99 is 5 seconds, 1 in 100 requests has a terrible experience. Always use percentiles, and never average them across machines: loadtest.dev merges the latency histograms from every container and reads percentiles from the result.