What a percentile tells you
P95 is the response-time threshold at or below which 95% of the measured requests fall. The remaining 5% are slower. P50 is the median, and P99 describes the slower tail more closely. These values describe the observed sample; they do not predict every future request.
An average combines all response times into one number. It can hide a small group of very slow requests when most requests finish quickly. Percentiles help you see that difference, but they still need context.
Compare the same thing
Compare percentiles for the same endpoint, environment, time window and workload. Combining a fast static endpoint with a slow search endpoint can produce a number that represents neither journey well.
Sample size matters. A short run with few requests can make a high percentile unstable. Keep the request count and test duration with the result rather than copying the percentile into a report on its own.
Read latency together with failures
A lower latency number does not always mean a healthier application. Requests rejected quickly can lower measured response time while users receive more errors. Check successful request rate, response codes and timeouts alongside latency.
- Look at P50 for the typical request.
- Use P95 or P99 to understand slower requests.
- Compare response time with throughput and error rate.
- Investigate changes against a recorded baseline.
Make the result actionable
Use a threshold that makes sense for the actual user journey, and record where it was exceeded. Then connect that observation to application monitoring. Database waits, exhausted connection pools and downstream calls can all contribute to a slow tail, so a percentile alone is not a diagnosis.