Every check PulseAPI performs records how long the HTTP request took. This article explains what response time means, what affects it, and how to interpret the data.
Response time is measured from the moment PulseAPI initiates the HTTP request to the moment the complete response is received. This includes:
https:// endpoints)It's a measure of the total round-trip time from PulseAPI's infrastructure to your endpoint and back.
Server-side processing time — the most common cause. If your application is slow to process the request (database queries, external API calls, heavy computation), response time increases.
Network latency — the distance and routing between PulseAPI's monitoring infrastructure and your server adds latency. This is fixed for a given server location but varies slightly due to routing changes.
DNS resolution time — occasionally, DNS lookups take longer than usual, adding a spike to response time.
TLS handshake — on the first check after a connection closes, TLS negotiation adds overhead. On keep-alive connections, this overhead is amortized.
Response body size — larger responses take longer to transfer. If you're monitoring an endpoint that returns a large payload, consider switching to a HEAD check or a lighter health endpoint.
Response times vary by endpoint, hosting provider, and geography. General expectations:
| Response Time | What It Suggests |
|---|---|
| < 200ms | Excellent — fast server and good network path |
| 200–500ms | Good — acceptable for most production services |
| 500ms–1s | Fair — may be worth investigating |
| 1s–3s | Slow — noticeable to users; investigate the bottleneck |
| > 3s | Very slow — likely causing user experience problems |
These are guidelines. What matters most is consistency — a stable 400ms is healthier than a response time that bounces between 100ms and 2000ms.
A single high response time (one check) is usually a transient network event or a brief server hiccup. It doesn't necessarily indicate a problem.
Sustained high response times (multiple consecutive checks) or a pattern of spikes at regular intervals (e.g., every hour) suggest a real issue worth investigating.
For response time spike troubleshooting, see Response Time Spikes Explained.
Still have questions? Contact support.