Skip to content
Multigrid

Latency Percentile Calculator

Paste your timings for p50 through p99.9, a histogram, a breach rate against your target, and an interval on every headline figure.

Everything on this page runs in your browser. Nothing you paste is uploaded, logged, or written into the URL — only the settings are, so a configured tool can still be linked to.

p95
180 ms

From 42 samples. The 95% interval on this figure runs 168 ms to 620 ms — anything inside that range is the same measurement, not an improvement.

p50p95118 ms620 ms15
One bar per bucket, tallest bar labelled on the left. The dashed lines are the median and the 95th percentile — the distance between them is the part of your latency budget that averages hide entirely.
value95% interval
Minimum118 ms
p50 (median)141 ms133 ms – 147 ms
p75154 ms
p90171 ms
p95180 ms168 ms – 620 ms
p99534 mstoo few samples
p99.9611 mstoo few samples
Maximum620 ms

Intervals come from the binomial distribution of the rank each percentile sits at — the honest statement of how much a percentile computed from a finite sample can move.

Samples
42
Mean
160 ms
Standard deviation
85 ms
Mean ÷ median — how far the average is dragged by the tail
1.14
Slower than your target
2 (4.8%)
Interval on that breach rate
1.3% to 15.8%
Samples needed before a p99 is meaningful
100 minimum, 1,000 to defend
  • warn42 samplesa 99th percentile needs at least 100 samples before it is anything but the largest value you happen to have — with 42, the p99 above IS essentially the maximum

    Expected: 100 samples for a p99 you can quote, 1,000 for one you can defend, and roughly 20 before even a p95 means much

  • warn2 of 424.8% of these calls were slower than 250 ms — 95% interval 1.3% to 15.8%

    Expected: an error budget you decided in advance. The interval is the part people skip: a breach rate measured on a few hundred samples is not precise enough to tell a 1% budget from a 3% one

What this checked: this sorts your numbers and computes both common percentile definitions — nearest-rank and linear interpolation — with an interval on each headline figure derived from the binomial distribution of its rank. It counts breaches against a target you set and puts a Wilson interval on that rate. It flags samples too small for the percentile you are reading, heavy tails, zeros, negative durations and the p95-to-median ratio that suggests two populations mixed together. It does not know where the numbers came from: it cannot tell time-to-first-token from total time, cannot tell a retry from a fresh call, and cannot tell whether your sample is representative of the traffic you care about. It also cannot detect the most common measurement bug of all, which is a sample that silently excludes the requests that timed out.
What this assumes: that each line is one independent measurement of the same thing. Percentile intervals use the normal approximation to the rank's binomial distribution, which is fine in the middle of the distribution and increasingly optimistic in the far tail — read the p99.9 interval as a floor, not a bound. Nearest-rank always returns a value you actually measured; linear interpolation returns a value between two of them and is what NumPy and most spreadsheets do by default, so two teams quoting "p95" from the same data can legitimately differ. On a small sample the difference is not small.

Percentiles do not add up, and this is where dashboards lie

You cannot average a p95. The p95 of five minutes of traffic is not the mean of five one-minute p95s, and no amount of weighting fixes it — the information needed to combine them was thrown away when each was computed. The same applies across shards, regions and services. If your monitoring stores pre-aggregated percentiles per interval, the number on the dashboard for the last hour is not a percentile of anything; it is a summary statistic of summary statistics, and it is usually optimistic. Storing histograms rather than percentiles is the fix, and it is why every serious latency system does.

Which clock, and what happened to the failures

For a streaming call there are three different latencies — time to first token, time to last token, and time per token after the first — and they behave completely differently. Time to first token is dominated by queueing and prompt length; total time is dominated by how much was generated. A p95 that mixes them describes nothing. Then there is the exclusion that flatters every latency graph ever drawn: the requests that timed out or errored have no duration, so they are not in the sample, so the slowest experiences your users had are precisely the ones your percentiles cannot see. Count them separately and quote them alongside, or the number above is an answer to a question nobody asked.

The reasoning behind this

Related tools

Latency Percentile Calculator · Multigrid