Latency Percentile Calculator
Compute p50, p90, p95 and p99 from a list of response times.
Paste a list of response-time (latency) measurements and this tool instantly reports the count, minimum, maximum, mean, plus the p50, p90, p95 and p99 percentiles. It works with anything in milliseconds — load-test output, the response-time column from access logs, or raw data exported from an APM. Values can be separated by newlines, commas or spaces.
A service that looks fine on average often reveals real user-facing delay at p95 and p99. Use this latency percentile calculator to expose tail latency and inform your SLO targets and performance-regression checks.
How percentiles are computed (nearest-rank)
This tool uses the nearest-rank method. Values are sorted ascending, then for a percentile p it picks rank ceil(p / 100 × N) (where N is the sample size). In code that maps to the zero-based array index ceil(p / 100 × N) - 1. Because no interpolation is used, every result is an actual measured value, matching the definition most monitoring tools use.
For example, with 100 samples the p95 is the 95th value in sorted order (index 94).
Why p95 and p99 matter more than the mean
The mean lets a few fast responses hide the slow ones. If a single request from one user is slow, that user feels it as slow — yet the average can still look healthy. Percentiles expose that tail directly.
- p50 (median): the latency a typical user experiences.
- p90 / p95: the slowest 10% / 5% of requests. A common SLO baseline.
- p99: the slowest 1%. When a page makes several backend calls, p99 delays accumulate and are felt by many users.
The more requests a screen composes, the bigger the impact of tail latency. A page built from 10 calls is far more likely to hit at least one call's p99, so the real rate of "slow screens" is much higher than any single call's p99.
Input format and handling
- Values are assumed to be in milliseconds (ms). Separate them with newlines, commas or spaces.
- Tokens that do not parse as numbers (headers, unit characters, etc.) are ignored automatically.
- Decimals and non-negative values are supported. All computation happens in your browser.
To gather individual measurements first, use the response time measurement tool to time a specific URL, then collect those values and feed them into this percentile calculator to analyze tail latency.
A worked example you can follow
Suppose you paste these 10 response times (ms): 120, 95, 130, 600, 110, 105, 1500, 125, 100, 115. Sorted, they become 95, 100, 105, 110, 115, 120, 125, 130, 600, 1500 (N = 10).
| Metric | Calculation | Result (ms) |
|---|---|---|
| Mean | sum 3000 ÷ 10 | 300 |
| p50 | ceil(0.50 × 10) = 5 → index 4 | 115 |
| p90 | ceil(0.90 × 10) = 9 → index 8 | 600 |
| p95 / p99 | ceil(0.95 × 10) = 10, ceil(0.99 × 10) = 10 → index 9 | 1500 |
The mean of 300ms looks merely "slow but tolerable," yet p90 is 600ms and both p95 and p99 are 1500ms. Notice that with only 10 samples, p95 and p99 collapse to the same value (the single slowest request) — a classic small-sample trap.
SLO target reference (by service type)
| Service type | Metric to track | Rough target |
|---|---|---|
| Interactive web API | p95, p99 | p95 < 200ms, p99 < 500ms |
| Internal microservice call | p99, p99.9 | p99 < 50ms |
| Static assets / CDN | p50, p90 | p90 < 100ms |
| Batch / async job | p50, max | size timeouts off the max |
Common pitfall
- Never average percentiles. Taking the mean (or sum) of p99 values from several servers or time buckets is mathematically wrong. Percentiles are not additive or averageable — to be correct you must pool all the raw measurements and recompute once over the combined set.
- p99 is meaningless on tiny samples. With fewer than ~100 samples, p99 effectively equals the maximum and is dictated by a single outlier. You need hundreds to thousands of data points before p99 is trustworthy.
- Mixed units. Pasting seconds (e.g.
0.12) alongside milliseconds (e.g.120) breaks the math. Normalize everything to ms before entering it.