API Response Time Calculator

p95 (the 95th percentile) means 95% of your requests complete within that time. Unlike the average, percentile metrics are not skewed by a small number of very fast requests — they reflect the actual worst-case experience for most users. If your API has an average latency of 120ms but a p95 of 800ms, one in twenty users is waiting 6× longer than average. For SLA commitments, p95 and p99 are the standard metrics used by cloud providers, APM tools, and engineering teams because they capture the real tail of the distribution.

p95 means 5% of requests are slower than that threshold; p99 means 1% are slower. p99 is the more conservative SLA target and is typically used for user-facing APIs where you want to ensure nearly every request is fast. p95 is commonly used for internal services or batch processing where occasional slow requests are more acceptable. A well-optimised API might target p95 < 200ms and p99 < 500ms. If your p99 is much higher than your p95, it indicates a heavy tail — usually caused by database lock contention, garbage collection pauses, or cold start effects.

Common industry benchmarks: user-perceived instant response is under 100ms; acceptable interactive response is 100–300ms; noticeable delay starts at 300ms; users lose focus at 1000ms (1s). For REST APIs: target p50 < 50ms, p95 < 200ms, p99 < 500ms for read endpoints. Write endpoints can be 2–3× slower. For background jobs, p99 < 5s is often acceptable. Google's Core Web Vitals target server response time (TTFB) under 800ms. The right target depends on your application type, user expectations, and infrastructure.

Standard deviation measures the spread or consistency of your response times. A low standard deviation (relative to your mean) means your API responds consistently — predictable and easy to reason about. A high standard deviation means high variability: sometimes fast, sometimes slow. High variability is often worse than uniformly slow responses because it is hard to cache or retry effectively. Causes of high latency variance include: cold starts, connection pool exhaustion, GC pauses, hot database rows, network jitter, and bursty upstream dependencies. Aim for a standard deviation less than 50% of your mean.

p99 is driven by your worst-case requests, so fixing it requires finding what makes slow requests slow. Common causes and fixes: (1) Database slow queries — add indexes, use EXPLAIN ANALYZE, cache hot reads. (2) N+1 queries — use eager loading or DataLoader. (3) Synchronous calls in hot paths — parallelise with Promise.all or async batching. (4) GC pressure in JVM/Node — tune heap size, reduce allocations. (5) Cold starts in serverless — use provisioned concurrency or keep-alive pings. (6) Connection pool exhaustion — increase pool size or use PgBouncer. Profile your slowest 1% of requests specifically — they often have a very different code path than fast requests.

An SLA (Service Level Agreement) is a commitment about your service's reliability and performance. For APIs, a common format is: 'p99 latency < 500ms, measured over a rolling 5-minute window, for 99.9% of calendar months'. To define yours: (1) Collect real production latency data for at least 7 days. (2) Look at your p99 — set your SLA target slightly above your current p99 to give headroom. (3) Define the measurement window (per-minute, per-hour, rolling 24h). (4) Define consequences for breaches (customer credits, alerting). Common SLA tiers: Bronze = p95 < 1s, Silver = p95 < 500ms + p99 < 1s, Gold = p99 < 200ms. This calculator helps you validate whether your current data meets a proposed SLA target.