How to Read a Load Test Report

Start with the question the test was meant to answer

Before judging a report, write down the goal. Were you checking whether a landing page survives launch traffic? Were you validating an API fix? Were you comparing two hosting setups? The same numbers can mean different things depending on the target, traffic level, and user journey.

Check request volume and test duration

Total requests and duration tell you the size of the sample. A tiny test is good for a smoke check, but it may not reveal periodic slowdowns. A longer run gives more confidence, especially when traffic reaches caches, databases, queues, and third-party services.

Read success rate before latency

Fast failures are still failures. If the report shows a high error rate, inspect status codes, timeouts, and network errors before celebrating low response times. A healthy report should show both acceptable speed and acceptable correctness.

Use latency percentiles to understand user experience

• Average latency gives a quick summary but can hide slow groups of requests.
• p50 latency shows the middle request and is useful for understanding the typical path.
• p95 latency shows whether most users stay within a tolerable wait time.
• p99 latency highlights rare but painful slowdowns that can affect important users.

Example report interpretation

If a report shows 50 total requests, 0 failed requests, p95 latency of 184ms, and 4.8 requests per second, the target handled that small scenario well. If the same test later shows p95 latency of 900ms and several timeouts, the change points to a new bottleneck or capacity issue worth investigating.

Compare RPS with latency

Requests per second shows throughput. Throughput is valuable only when latency and error rate stay under control. If RPS rises while p95 latency climbs sharply, the system may be queueing work instead of handling traffic comfortably.

Investigate status codes

Status codes show the shape of failures. A spike in 401 or 403 responses may point to missing authorization headers. A 404 may mean the wrong URL was tested. A 429 often means rate limiting. A 500-level response suggests the application or infrastructure failed while processing the request.

Look for timeout and network patterns

Timeouts usually mean requests exceeded the configured wait limit. Network errors can come from DNS, connection resets, unreachable hosts, blocked traffic, or TLS problems. These metrics are especially important when an app appears healthy at low traffic but becomes unreliable as concurrency increases.

Decide what to do next

1. If errors are high, fix correctness before optimizing speed.
2. If p95 or p99 is high, inspect slow queries, external calls, queueing, and cold starts.
3. If throughput is lower than expected, check server limits, connection pools, worker counts, and rate limits.
4. If results look good, rerun the same scenario later to make sure the improvement is repeatable.

Keep a baseline

Save JSON or CSV reports so future changes have something to compare against. You can also view a sample load test report to see how the metrics fit together, then run your own small controlled test.