What each metric means
LoadBolt shows you five core metrics after every test run:
- Latency percentiles (p50, p90, p95, p99) — response time at different points in the distribution. p50 is the median (half your requests were faster), p95 means 95% of requests were this fast or faster. The p95 is usually the one to watch.
- Average latency — the arithmetic mean. Useful for a rough feel, but percentiles tell the real story because averages hide spikes.
- RPS (requests per second) — throughput. How many requests your server handled. LoadBolt shows both average and peak RPS.
- Total requests — the total count of HTTP requests made during the test.
- Error count & rate — how many non-2xx responses were returned, and the percentage. Any response that isn't 2xx counts as an error.
What's “good”?
There's no universal answer — it depends on your app. But here are some rules of thumb:
- p95 latency < 500ms — most web APIs should respond within half a second for the vast majority of requests
- Error rate < 1% — a few errors under heavy load can be normal, but more than 1% usually signals a problem
- Flat latency as VUs increase — if your p95 stays roughly the same as you add more virtual users, your app is scaling well
These are starting points. A real-time chat API might need p95 < 100ms. A batch processing endpoint might be fine at 2 seconds. You know your app best.
Reading the charts
LoadBolt gives you three charts, all showing data in 1-second buckets over the duration of your test:
Response Time chart
Shows latency over time with lines for p50, p90, p95, and p99. Look for the shape: flat lines mean stable performance. A gradual upward slope means your server is getting slower as load increases. A sharp spike usually points to a specific bottleneck kicking in.
Throughput chart
Shows successful requests per second and errors per second side by side. Healthy servers show steady RPS with few or no errors. If RPS plateaus while VUs keep climbing, your server has hit its throughput ceiling.
Virtual Users chart
Shows how many concurrent VUs were active at each second. If you used ramp-up, you'll see a gradual climb. This chart helps you correlate “we had X users and latency did Y.”
Per-endpoint breakdown
If your script hits multiple URLs, LoadBolt breaks down metrics for each one. This is where you find the slow route. Maybe /api/users responds in 50ms but /api/reports takes 2 seconds. You wouldn't see that in the aggregate numbers.
Error breakdown
LoadBolt groups errors by HTTP status code. Here's what the common ones mean in a load test context:
- 403 Forbidden — your WAF or firewall is blocking test traffic. See our allowlisting guide.
- 429 Too Many Requests — you're hitting a rate limiter. Either allowlist LoadBolt or reduce VUs.
- 500 Internal Server Error — your app is crashing under load. This is the kind of thing you want to find before users do.
- 502 Bad Gateway — your reverse proxy or load balancer can't reach your app server. Often means the app process has run out of memory or crashed.
- 503 Service Unavailable — your server is explicitly saying it's overloaded. Usually means a connection pool is exhausted or the server is in a degraded state.
Live metrics vs final results
While a test is running, LoadBolt streams metrics to your browser in real-time — updated every second. The charts and numbers you see are live. Once the test finishes, you get the complete picture with final aggregated stats. Both views show the same data; the final results just include the full duration.
Exporting results
You can export any test run in three formats:
- PDF — a formatted report with charts. Great for sharing with stakeholders or attaching to a ticket.
- CSV — raw data you can open in a spreadsheet. Good for custom analysis.
- JSON — structured data for automation. Pipe it into your CI pipeline or monitoring system.
Common patterns to look for
After running a few tests, you'll start recognizing shapes:
- Flat latency — healthy. Your server handles the load without breaking a sweat.
- Hockey stick — latency is flat then suddenly shoots up. Classic saturation pattern. Your server is fine until it hits a limit (CPU, memory, DB connections), then everything degrades fast.
- Errors during ramp-up — errors appear as VUs increase. This tells you your capacity limit. The VU count where errors start is your practical ceiling.
- Gradual climb — latency slowly increases with VU count. No hard breaking point, but you're approaching the limit. Scale up before you get there.