Service can have a reassuring average response time while some customers wait several seconds. P95 and P99 latency help you see those slower requests and judge whether performance remains acceptable under load.

This guide explains how to read latency percentiles, calculate them from a sample, and use them in performance tests. Every number in the examples below is illustrative, rather than a benchmark for your application.

What do P95 and P99 latency mean?

Latency is the elapsed time for an operation. Before comparing results, define the measurement boundary-server's processing time, an API round trip measured by a client, or a complete user journey. These are different measurements.

Percentile describes a position in a distribution of observations.

Metric Meaning What it helps you see
P50 The median: approximately 50% of observations are at or below this value. Typical request performance
P95 Approximately 95% of observations are at or below this value. The slower end of common request experiences
P99 Approximately 99% of observations are at or below this value. A more extreme part of the latency tail

If an API's P95 is 400 ms and its P99 is 1,200 ms, roughly 95% of measured requests finish within 400 ms and roughly 99% finish within 1,200 ms. The slowest requests can take longer still. Neither percentile is a maximum or a guarantee for the next request.

These percentages describe requests in the measured population, not necessarily percentages of users. One user may make many requests, and one page may call multiple APIs.

Why the average can hide slow requests

Imagine 1,000 requests: 990 take 100 ms each and 10 take 5,000 ms each. Their average latency is:

(990 × 100 + 10 × 5,000) / 1,000 = 149 ms

That average looks fast, even though ten requests take five seconds. With the nearest-rank percentile method, both P95 and P99 are 100 ms in this exact sample the maximum is 5,000 ms. This is also a reminder that P99 can miss problems confined to the slowest 1%.

Read percentiles alongside request volume, errors, timeouts, and the distribution itself. Histogram can reveal a second group of slow requests that a single summary value conceals.

How to calculate a percentile

One simple definition is the nearest-rank method

  1. Sort the observed durations from fastest to slowest.
  2. Multiply the number of observations by the percentile expressed as a fraction.
  3. Round up to the next integer to get a one-based rank.
  4. Select the observation at that rank.

For 1,000 observations, P95 uses rank 950 and P99 uses rank 990.

rank = ceil(percentile / 100 × number_of_observations)
P95 = sorted_durations[950th observation]
P99 = sorted_durations[990th observation]

Tools can use interpolation, histogram estimates, or other quantile algorithms, so they can report slightly different values for the same data. Document the method when comparing reports, especially when sample sizes are small.

With only 100 observations, the nearest-ranked P99 is the second-slowest observation. That is a fragile basis for a performance claim. Collect enough observations and inspect variability across multiple comparable runs.

Reading P95 and P99 together

Consider two illustrative load-test runs for the same endpoint, with the same request mix and comparable infrastructure:

Run P50 P95 P99 Error rate
Baseline 120 ms 300 ms 450 ms 0.1%
Higher load 130 ms 350 ms 1,800 ms 0.1%

The typical request changed little, but the upper tail became much slower. Possible contributors include queueing, connection pool contention, database locks, garbage collection pauses, cache misses, retries, or slow downstream calls. The percentiles show a symptom and they do not identify the cause.

Investigate slow-request traces and correlate the affected time windows with traffic, resource saturation, dependency latency, and deployment events. Compare like-for-like requests before drawing conclusions.

Setting useful performance targets

There is no universal good P95 or P99. A checkout request, a search query, and an asynchronous report have different user expectations and operating constraints.

Define the endpoint or journey, measurement boundary, traffic conditions, evaluation window, and threshold together. For example

During a 30-minute steady-state test at 200 requests per second with the agreed production request mix, the checkout API's client-measured P95 must be at most 500 ms and P99 at most 1,000 ms. Errors must remain below 0.1%; timeouts must be reported separately.

Those values are examples, not recommended defaults. Choose targets from user needs and production evidence. For an operational service-level objective, directly measured fraction of eligible requests below a threshold is often easier to evaluate against an error budget than a percentile alone.

Common mistakes that distort the results

Averaging percentiles across servers or time windows

The average of several P99 values is not the P99 of their combined requests. Different populations and traffic volumes make this especially misleading. Combine raw observations or compatible histogram distributions first, then compute the percentile for the combined population. Some precomputed summary quantiles cannot be aggregated this way.

Mixing unrelated endpoints

Fast health checks can dominate a service-wide distribution and obscure a slow business transaction. Report percentiles by meaningful endpoint or journey, while retaining a service-level overview. Avoid telemetry labels with unbounded values such as individual user IDs.

Ignoring failures and timeouts

Fast error response can improve the apparent latency while the service becomes less useful. Report success latency and failure latency separately, and always show error and timeout rates. Requests terminated by a timeout may not reveal their eventual completion duration; disclose how the tool records them.

Measuring only completed requests during overload

Some load generators wait for one response before sending the next request. When the application slows, the offered traffic falls, potentially understating the queueing a real arrival stream would create. This measurement problem is often called coordinated omission. Choose a workload model that matches expected arrivals, track achieved and offered request rates, and investigate dropped iterations or generator limits.

Comparing incompatible tests

Changing the request mix, payload sizes, data set, cache state, region, or measurement window can change percentiles without any code regression. Record these conditions. Separate warm-up from steady-state measurements and examine time-series windows so a brief incident is not hidden inside a long run.

Practical load-test review checklist

  • Define where each latency measurement starts and ends.
  • Check request counts, offered load, achieved throughput, and generator health.
  • Review P50, P95, P99, errors, and timeouts for important endpoints.
  • Inspect histogram shape and changes over time, rather than only whole-run summaries.
  • Compare equivalent workloads and repeat tests when results vary.
  • Use traces and resource metrics to investigate the slowest requests.
  • Re-run the same workload after a fix and check for trade-offs in throughput or reliability.

P95 and P99 turn vague statements such as “the API is usually fast” into measurable observations. They are most useful when the population and measurement conditions are explicit, and when you combine them with errors, throughput, and evidence from individual slow requests.

Get help measuring tail latency

Loadtest helps teams design realistic workloads, interpret latency distributions, and investigate performance bottlenecks. Explore our application performance testing services and observability engineering services, or contact us to discuss your application.

Further reading