Slowest and Most Failing Requests

Slowest and most failing requests

For a test with more than one request, the Overview shows two short lists under the metric tiles: the five requests with the highest average response time, and - when the run had errors - the five with the highest error rate. Each row links to that request in the Stats table.

How they are ranked

• Slowest sorts by average response time and shows the maximum next to it. A request with a modest average and a huge maximum is a request that is usually fine and occasionally stalls - a lock, a cold cache, a garbage-collection pause.
• Most failing sorts by error rate, then by the number of errors. A request with 100% errors and few samples is usually a script problem (wrong URL, missing token); a request with 3% errors and thousands of samples is capacity.

Both lists use the exact per-sample data of the run, so they agree with the Stats table.

What to do with them

1. Open the request in the Stats table and compare its P95 with the run's P95 on the Overview. One request pulling the whole run's percentile up is the usual case.
2. Check whether it is slow everywhere or from one location.
3. If it fails, look up its failure type in the errors by type table.
4. Set a pass/fail threshold so the next run tells you whether the fix worked; the Stats table marks each request against it.