P90, P95 & P99 Latency Simulator
Learn latency percentiles with an interactive simulator. Generate request samples, visualize distributions, compare average latency with P50, P90, P95, and P99, and see how tail latency affects real users.
Category: Monitoring
What You Will Learn
- Understand that P90, P95, and P99 are percentile rank cutoffs
- Visualize how latency distributions create long-tail behavior
- Compare average latency, median latency, and percentile latency
- See why P99 exposes slow requests that averages can hide
- Practice choosing the right latency metric for SLOs and incident response
Topics covered: latency, percentiles, p90, p95, p99, monitoring, observability, sre, performance, slo, educational, interactive
// simulator
P90, P95 & P99 Latency Simulator
Learn latency percentiles with an interactive simulator. Generate request samples, visualize distributions, compare average latency with P50, P90, P95, and P99, and see how tail latency affects real users.
Generate a latency sample, sort every request, and watch how a tiny slow tail changes the numbers your dashboards show.
P95 means 95% of requests finished in 90ms or less. The remaining 5% were slower.
Only the slowest 5% are above this line.
Can hide a painful tail
Median request
10% are slower
5% are slower
1% are slower
Latency distribution
The bars show request counts by latency bucket. Vertical lines mark percentile cutoffs.
Request stream
Each square is one request in arrival order.
P99 is 3.2x the median in this sample. If average and P50 look fine while P99 jumps, optimize the rare slow path: cache misses, cold starts, retries, lock waits, noisy nodes, or downstream calls.
Sorted request ruler
Requests are sorted fastest to slowest. Percentiles are rank positions, not averages.
First 90%
Normal user experience. This is what average dashboards over-emphasize.
Next 9%
Slow requests. P95 is usually where support tickets start to appear.
Slowest 1%
The tail. P99 tells you whether rare paths are painful.
Incident readout
Which metric would catch the user pain?
P90
80ms10% of requests are slower than this cutoff.
P95
90ms5% of requests are slower than this cutoff.
P99
193ms1% of requests are slower than this cutoff.
What the numbers say
P90: 80ms means 90% of sampled requests completed by that point. It describes the upper edge of normal.
P95: 90ms leaves only 5% of requests above it. It is a practical SLO metric because it catches recurring pain without being as jumpy as P99.
P99: 193ms isolates the slowest 1%. In this run, that group averages 212ms, while the median is only 60ms.
How P90, P95, and P99 latency work
Percentiles are sorted ranks
- P90: sort every request by latency. The P90 value is the point where 90% of requests are at or below that value.
- P95: leaves only the slowest 5% above the cutoff, which makes it useful for SLOs and user-facing dashboards.
- P99: focuses on the slowest 1%, so it exposes rare but painful paths that averages often hide.
Why average is not enough
- A few very slow requests can be invisible when the median and average look normal.
- Tail latency often comes from retries, lock waits, cold starts, cache misses, or slow dependencies.
- Percentiles show how many users are affected, not just how slow the typical request is.
How to use them in practice
- Use P50 to understand the normal request path.
- Use P90 or P95 to track broad user experience and SLO health.
- Use P99 to investigate tail events, capacity limits, and reliability regressions.
Try next
// simulator
Agentic Loop Simulator
Watch a coding agent run an agentic loop, one step at a time. A planner, a builder, and a judge cycle through plan, build, verify, and repeat until the goal is met. Toggle the separate judge off to see why an agent grading its own work ships confident bugs. An animation-first, interactive explainer of loop engineering and how it maps to Claude Code.
// simulator
SQL Terminal Simulator
Practice SQL in an interactive browser terminal. Learn SELECT, WHERE, ORDER BY, DISTINCT, aggregates, GROUP BY, HAVING, JOINs, subqueries, and window functions against a small e-commerce schema, with single-table queries evaluated live and verified Postgres output.
// simulator
PostgreSQL Terminal Simulator
Practice the psql tool and Postgres engine in an interactive browser terminal. Explore with meta-commands, read real EXPLAIN plans, add an index to turn a sequential scan into a bitmap index scan, and use BEGIN and ROLLBACK to make changes safe, all against a small e-commerce database with verified PostgreSQL output.