Glossary
Response time
Response time is how long a request took to answer, measured end to end by the thing doing the asking.
Also called Latency.
Response time is the elapsed time between sending a request and receiving the answer. Measured by a monitor it includes everything in the path: DNS resolution, TCP connect, the TLS handshake and the server's own work, up to the moment the response headers arrive. That is exactly why it is useful. It is the number your users experience rather than the number your application logs.
Averages hide the interesting part. If ninety-nine requests take 100ms and one takes ten seconds, the mean is a healthy 199ms and one customer had a terrible time. Percentiles are what teams actually watch: p50 for the typical experience, p95 and p99 for the tail where the complaints come from. A rising p99 against a flat p50 is a real signal, and it is invisible in an average.
Response time is also a leading indicator of downtime. Most outages announce themselves as a slow slide in latency before anything starts failing outright, which is why a threshold on response time catches a saturating database or an exhausted connection pool while it is still a degradation rather than an outage.
One measurement to be careful with: the response time recorded on a FAILED check is not latency. It is how long the probe waited before giving up. Averaging timeouts into a latency chart draws a spike out of an outage and makes the two indistinguishable.
| Metric | What it tells you | Watch it for |
|---|---|---|
| Average (mean) | Total time divided by the number of requests. | A rough trend line. One very slow request barely moves it. |
| p50 (median) | Half of all requests were faster than this. | The typical experience. When it rises, most users feel it. |
| p95 | The slowest 1 request in 20 took at least this long. | Early saturation: queues, a busy database, a cold cache. |
| p99 | The slowest 1 request in 100 took at least this long. | The tail your heaviest users hit, where complaints start. |
| Time to first byte | How long until the first byte of the answer arrived. | Server work, separated from the time spent downloading. |
Questions
What is a good response time?
For anything a person waits on, Jakob Nielsen's three limits still hold: about 0.1 seconds feels instant, about 1 second keeps their train of thought, and about 10 seconds is the limit of their attention. An API behind a page should sit well under the first, because the page adds its own time on top. Judge it at p95, not on the average.
What is the difference between response time and latency?
Strictly, latency is the time a request spends travelling or waiting, and response time is the whole round trip, the server's own work included. In everyday use the two words are swapped freely. A monitor measures response time: from sending the request to receiving the answer.
What is response time monitoring?
Timing the same request on a schedule, from outside your own system, and alerting when it gets slow. It answers the question uptime alone cannot: the service is up, but is it fast enough to use? A threshold on response time catches a degradation while it is still a slowdown rather than an outage.
Which response time metrics should I track?
The median for the typical experience and p95 or p99 for the tail, with the average kept only as a trend line. Chart them over the same window, and alert when response time stays high across several checks rather than on one slow request.
Does a timed-out check count as a slow response?
No. A check that timed out never got an answer, so the time recorded is how long the monitor waited before giving up. Count it as a failure and keep it out of latency charts, or an outage shows up there as a latency spike.
In Uptimely
Uptimely records response time on every check and charts it per monitor. Monitor criteria can compare response time against a threshold, either on the check that just ran or averaged over a window, so a slow-but-answering service can raise an alert without being declared offline. The response-time chart on a public status page plots successful checks only, for the reason in the last paragraph above.
Uptimely records response time on every check, as often as every minute on every plan, and a monitor's criteria can flag it when it crosses a threshold.
Start monitoring free →Product feature
Part of the Uptimely monitoring glossary — plain definitions of the vocabulary uptime monitoring, incident response and status pages are discussed in. Something here read wrong to you? Email support@getuptimely.com.