Latency Percentile Calculator

Paste a list of response times and get the percentiles that matter — p50, p90, p95, p99 and p99.9 — instead of an average that hides the slow tail. Everything runs in your browser.

Your measurements

Latency values

Response times

Paste your numbers — separated by spaces, commas or new lines. Use one unit (ms or seconds) consistently; the results come back in the same unit.

Percentiles

p99 —

99% of your measurements are at or below this. The slowest 1% are worse.

p50 (median)—

The typical request. Half are faster, half slower.

p90—

Nine in ten requests are at or below this.

p95—

Nineteen in twenty requests are at or below this.

p99.9—

Only 1 in 1,000 requests is slower. Needs a lot of samples to be stable.

Min / Max—

The fastest and slowest single measurements.

Mean—

The average — shown for comparison. Notice how far it sits from p99.

Count—

How many values were parsed. More samples make the tail percentiles trustworthy.

See how your response times are spread

How many requests fell at each speed

Each bar counts requests in one speed range. Most sit in the tall group on the left; the long thin tail on the right is what the p95 and p99 lines point at.

Tail latency amplification

One user action often triggers many backend requests. If any of them is slow, the whole action feels slow. Enter how slow-prone a single request is and how many run per action to see the real hit rate.

Why percentiles, not averages

An average latency of 120 ms sounds fine. But if 1% of requests take three seconds, that average barely moves while a real slice of users has a bad time. Percentiles keep the tail visible: p95 and p99 tell you how slow the slow requests are, and how many there are. Most latency targets are written as a percentile for exactly this reason.

Reading the numbers

p50 is the median — the typical request.
p90 / p95 is the everyday worst case most users will notice at some point.
p99 is the tail. On a busy service, 1% of requests is still a large number of unhappy sessions.
p99.9 is the extreme tail. It needs tens of thousands of samples to be stable, and it is where retries, garbage collection pauses and cold caches show up.

A caveat: coordinated omission

If your measurements come from a load test or client that waits for each response before sending the next, a slow response also delays every request queued behind it — but those delays are not recorded. This makes the tail look better than it is. Tools that account for this (or open-loop load generators) give more honest tail numbers.

Frequently asked questions

What does p99 latency mean?

p99 is the value that 99% of your measurements are at or below. If p99 latency is 800 ms, then 99% of requests were faster than 800 ms and the slowest 1% were slower. It describes the tail, which is where users actually feel slowness.

Why not just use the average latency?

The average hides the tail. A service can average 120 ms while 1% of requests take 3 seconds. Users remember the 3-second ones. Percentiles (p95, p99, p99.9) show how bad the slow experiences are and how common they are.

How does this calculator work out the percentiles?

It sorts your values and uses linear interpolation between the two nearest ranks (the same method as NumPy's default and most spreadsheets). For a percentile p, the position is p/100 × (count − 1).

How many samples do I need for a reliable p99?

As a rough guide, you want at least a few hundred samples for a stable p95, around a thousand for p99, and tens of thousands for p99.9. With too few samples the tail percentiles jump around between measurement windows.

What is tail latency amplification?

When one user action makes many backend requests, the chance of hitting at least one slow request multiplies. If 1% of requests are slow and a page makes 20 of them, roughly 18% of page loads contain a slow request — far worse than the 1% you would guess.