Calculating...
Choose a mode, fill in the parameters, and click Calculate →
What is API Response Time?
API response time is the total elapsed time between a client sending a request and receiving the complete response. It is composed of four distinct phases: DNS resolution (looked up via your DNS Record Lookup tool), TLS handshake (visible via our SSL Certificate Checker), network transit time (governed by physical distance and bandwidth — see our Bandwidth & Data Transfer Calculator), and server processing time (parsing the request, querying databases, and serialising the response).
Measuring only the mean (average) hides the true user experience. A service that returns 10 ms for 95% of requests and 5,000 ms for the remaining 5% has an average of 260 ms — which sounds acceptable but means 1-in-20 users waits 5 seconds. The Google SRE Book's chapter on Service Level Objectives explicitly recommends using percentile-based SLOs (P95, P99) rather than mean response time for this reason.
Network hardware bottlenecks can also introduce latency before your application code is even reached. Use our CPU & GPU Bottleneck Calculator to rule out hardware constraints on the server side, and our Ping & Latency Impact Calculator to understand how raw network round-trip time compounds with application processing time.
How to Read Latency Percentiles
A percentile value answers: "What is the response time that X% of requests complete within?" Most monitoring tools (Datadog, Grafana, Prometheus) expose P50, P95, P99, and P99.9 out of the box. Gil Tene's HdrHistogram library is the standard for high-accuracy latency recording — it avoids the "coordinated omission" problem that corrupts measurements from simple sliding-window histograms.
| Percentile | Meaning | At 1,000 req/s |
|---|---|---|
| P50 | Half of requests complete within this time (median) | 500 req/s are slower |
| P95 | 95% of requests complete within this time | 50 req/s are slower |
| P99 | 99% of requests complete within this time | 10 req/s are slower |
| P99.9 | 99.9% of requests complete within this time | 1 req/s is slower |
P99 is the most actionable SLO target for user-facing APIs. P99.9 matters for internal infrastructure services called millions of times per second — at 10 M req/s, even 0.1% slow requests equals 10,000 degraded calls per second, each potentially holding a thread or goroutine. For HTTP-level context, see our HTTP Status Code Reference and HTTP Headers & RFC Reference to understand timeout and retry semantics.
SLA Uptime Nines Reference
An SLA (Service Level Agreement) uptime percentage translates into a maximum allowed downtime window. "Nines" count the 9s — three nines means 99.9%. The Google SRE Book availability table is the canonical industry reference. Higher nines require progressively more investment: multi-region redundancy, automatic failover, zero-downtime deployments, and extremely disciplined change management. Gaining one extra nine typically costs 10× more effort than the previous one. For internal services, use the SLA → Downtime mode above to calculate exact budget figures for your team's planning.
| SLA | Label | Per Month | Per Year |
|---|---|---|---|
| 99% | Two Nines | 7h 18m | 3d 15h 36m |
| 99.9% | Three Nines | 43m 49s | 8h 45m 57s |
| 99.99% | Four Nines | 4m 22s | 52m 35s |
| 99.999% | Five Nines | 26s | 5m 15s |
Latency Budget Calculator Guide
In a microservices architecture, a single user-facing request fans out into multiple downstream service calls. Each call consumes a slice of the total latency budget. If your end-to-end P99 target is 200 ms and you make 5 sequential calls, each service must complete its P99 in under 40 ms — before accounting for network overhead. In practice, sequential service calls are rare; most architectures scatter-gather in parallel, so the budget is dominated by the slowest of the parallel group, not their sum.
Network round-trip time (RTT) within the same data-centre rack is typically 0.05–0.2 ms. Within a data centre it is 0.5–2 ms. Across availability zones in the same region it rises to 1–5 ms, and cross-region (e.g. US-East to EU-West) adds 80–120 ms. These costs compound with every service hop. Use our Network Speed to Transfer Time Calculator to model data transfer overhead, and our Bandwidth Calculator to check whether payload size (JSON response bodies) is introducing its own latency at your network throughput. For service-mesh and inter-service networking, our CIDR Notation Calculator and Subnet Calculator help plan the underlying network topology.
If the remaining per-service budget after network deduction falls below 10 ms, consider parallelising calls, adding a read-through cache (targeting sub-millisecond hit latency), or switching for synchronous calls to event-driven async messaging where user-perceived latency is less strict.
Related Developer & Network Tools
API response time is one layer of a larger system. These tools cover adjacent layers of the stack:
Frequently Asked Questions
What is a good API response time?
For interactive user-facing APIs: P50 under 100 ms feels instant, P99 under 300–500 ms is acceptable, and above 1 s users notice the delay. Internal microservice calls typically target P99 under 50 ms. The Google RAIL model sets 100 ms as the threshold for "instant" user perception. The right target depends on your SLA, whether the call is on the critical render path, and whether it is synchronous (blocks a page render) or asynchronous (background job).
How do I reduce P99 latency without affecting P50?
High P99 with low P50 indicates a bi-modal distribution — most requests are fast, but a subset hits a slow path. Common causes: cache misses on cold or rare queries, database queries that skip an index on unusual input values, GC pause spikes in JVM or Go runtimes, or lock contention under high concurrency. Profile the slowest 1% of requests in your APM tool (Datadog, Jaeger, Tempo) to identify the slow code path. Look for our RegEx Tester if slow log-parsing regex is a contributing factor, and the CRC Checksum Calculator if data integrity validation overhead appears in your traces.
What is the difference between latency and throughput?
Latency measures how long a single request takes (milliseconds per request). Throughput measures how many requests a system handles per unit of time (requests per second). They are related but independent: a system can have low latency at low load but high latency when throughput approaches capacity due to queuing. Little's Law formalises this: average latency = average concurrency (in-flight requests) / throughput. Doubling throughput without adding capacity doubles concurrency and latency. Use the Latency Budget mode above to model your per-service allocation at a given throughput target.
When should I use circuit breakers?
Use circuit breakers when a downstream dependency can become slow rather than fast-failing. Without one, slow calls hold goroutines or threads, queues build up, and the cascade backs up into upstream services — the "latency amplification cascade." Martin Fowler's Circuit Breaker pattern is the standard reference. Implement it with libraries like Netflix Hystrix, Resilience4j (JVM), or the failsafe-go package (Go). A circuit breaker opens after a configurable failure-rate threshold and immediately returns an error or cached fallback, protecting the system until the downstream recovers.
What causes bi-modal latency?
Bi-modal latency — a fast cluster and a slow cluster in the histogram — is almost always a cache-hit vs. cache-miss split. Cache hits are sub-millisecond memory reads; misses fall through to a database or remote service call, adding 20–500 ms. Solutions: increase cache TTL, pre-warm the cache on service startup, use a read-through cache pattern, or return stale data while revalidating asynchronously (stale-while-revalidate). Auth-token validation can also introduce bi-modality: use our JWT Token Decoder to check token expiry — a token expiring mid-session forces a synchronous refresh call that appears as a latency spike.
How does DNS affect API response time?
DNS resolution adds 1–100+ ms to the first request to a new hostname depending on whether the record is cached and the TTL. HTTP clients re-use connections (keep-alive) so DNS is only paid on the first connection or after TTL expiry — but in serverless functions and short-lived containers it is paid for every cold start. Strategies: shorten DNS TTL only when planning infrastructure changes (use 300s otherwise to allow caching), use a split-horizon DNS to keep internal service calls within the VPC, and prefer CNAME lookups over A-record lookups for services behind a load balancer. Use our SSL Certificate Checker to verify TLS configuration — a misconfigured cert triggers a full fallback handshake that can add 200–500 ms to the first connection.