Understanding Latency vs Response Time

The confusion

Latency and response time are often used interchangeably, but they measure different things. Understanding the distinction is crucial for effective monitoring and performance optimization.

The key difference:

Latency measures network travel time
Response time measures total time including server processing

Both metrics matter, but for different reasons.

What is latency?

Latency and response time are two different metrics used in uptime monitoring. Latency measures the time it takes for a request to travel from the probes to the server and back. Response time is the time it takes for the server to process the request and send back a response, plus the latency.

openstatus                  Network                 Server (Website)
  |                           |                          |
  |------- Request ---------->|                          |
  | (Timestamp A: Send)       |                          |
  |                           |------- Process --------->|
  |                           | (Server processing time) |
  |                           |<------- Response --------|
  |                           | (Timestamp B: Receive)   |
  |                           |                          |
Latency = Timestamp B - Timestamp A

Latency is the time it takes for data to travel from its source to its destination. Think of it as the round-trip time (RTT) for a network packet. This delay is influenced by several factors:

Distance: The physical distance between the client and the server. Data traveling across continents will have higher latency than data traveling within the same city.
Network Congestion: When too much data is on the network, it can slow down transmission, similar to a traffic jam on a highway.

To measure latency, you can monitor endpoints like /ping or /healthcheck with minimum server processing time.

What is response time?

    openstatus                 Network                Server
        |                         |                     |
(Start) |------- Request -------->|                     |
(T1)    |                         |                     |
        |                         |--- Processing ----->|
        |                         |   (Server's work)   |
        |                         |<-- Response Data ---|
        |                         |                     |
(End)   |<--- (Received) ---------|                     |
(T2)    |                         |                     |

 Response Time = T2 - T1

Response time is the total time from the moment a user's request is sent until the server's response has been fully received. It includes the network latency, the server's processing time, and the time spent streaming the response body back.

Response time = network latency + server processing time + transfer time

The server processing time is the duration the server spends on tasks like:

Executing database queries.
Running application logic.
Generating the HTML or JSON response.

A high response time often indicates a problem with the server-side application itself. For example, slow database queries or inefficient application code can dramatically increase the response time, even if the network latency is low.

The request in phases: DNS, TCP, TLS, TTFB, transfer

"Latency" and "response time" are summaries. A single request is really five consecutive phases, and knowing which one is slow is the difference between guessing and fixing. openstatus records each phase as its own duration:

Phase	What it measures	What a slow number means
DNS	Resolving the hostname to an IP address	Slow or distant nameservers, or a TTL so short that nothing is ever cached
Connect	The TCP handshake opening the socket	Mostly physical distance. This is the phase a CDN or edge deployment shortens
TLS	Negotiating the encrypted connection	A long certificate chain, no session resumption, or an old TLS version
TTFB	Request sent → first byte of the response returns	Your application's own work: database queries, rendering, upstream API calls
Transfer	Streaming the rest of the response body	A large payload, no compression, or a slow link

Two clarifications that trip people up.

TTFB here is a phase duration, not a cumulative timer. Many tools define "time to first byte" as everything from the start of the request — DNS, connect, and TLS included. In this breakdown those phases are already accounted for separately, so TTFB isolates the part your server is actually responsible for. A 40ms TTFB behind a 300ms connect phase is a fast application sitting a long way from the probe.

Response time is the sum, not the first byte. The connection phases — DNS, connect, and TLS — are the network cost of getting there before your application does any work. Add TTFB and transfer and you have total response time, which is what a user waits through.

This is also why a single number hides the diagnosis. Two endpoints both answering in 600ms are not equivalent if one spends 500ms in TLS and the other spends 500ms in TTFB. The first is a connection problem you fix with infrastructure; the second is code.

Why the distinction matters for uptime monitoring

Understanding the difference between these two metrics is crucial for diagnosing performance issues.

If your monitoring shows a high response time but low latency, the problem is likely with your server's performance. You should investigate your application's code, database queries, and server resources.
If both your latency and response time are high, the issue is likely network-related. This could be due to a poor connection between the monitoring location and your server, or a broader network issue.
Response time is the ultimate measure of user experience because it reflects the full journey of a request. Users don't just care how fast a packet can get to the server; they care how long it takes to see the results.

By monitoring both metrics, you can quickly pinpoint whether a performance slowdown is caused by your application or by the network.

Practical implications

For monitoring strategy

Monitor both metrics: Don't rely on just one
Set appropriate thresholds: Latency thresholds should be lower than response time thresholds
Consider geographic factors: Latency varies by monitoring location
Track trends: Sudden changes in either metric indicate issues

For optimization

Reduce latency: Use CDNs, optimize routing, choose closer hosting
Improve response time: Optimize code, database queries, caching
User location matters: Users far from your server will always see higher latency

Common scenarios

Scenario 1: consistent latency, variable response time

Indicates server-side performance issues.
Look at: database queries, API calls, resource utilisation.

Scenario 2: high latency from specific regions

Indicates geographic network issues.
Solution: add regional monitoring points or a CDN.

Scenario 3: both metrics degrading

Could be network saturation or a DDoS attack.
Check: network bandwidth, traffic patterns, security.

How to measure both

You need two things: the phase breakdown, and more than one vantage point.

For a single check right now, run the URL through the global speed test. It requests from 28 regions in parallel and returns all five phases per region, which is enough to tell a distance problem from an application problem in one pass. No account required.

For anything you care about over time, one sample is not evidence. Latency moves with traffic, deploys, and time of day, so a number from a single moment tells you almost nothing about the distribution your users actually see. Uptime monitoring re-runs the same check on a schedule, keeps the history, and alerts on degradation rather than only on failure — which is the difference between finding out from a graph and finding out from a customer.

Whichever you use, measure from where your users are. A check that only runs from the same continent as your origin will report healthy numbers indefinitely while users on the other side of the world time out.

What openstatus tracks

openstatus monitors and displays:

Total response time — the complete user experience.
Detailed timing breakdown — DNS, connect, TLS, TTFB, and transfer.
Regional differences — compare performance across locations.
Historical trends — identify patterns over time.

Latency and response time are the raw measurements. These build on top of them:

What is a good response time? — target numbers for both the server and the browser half, judged at the right percentile.
SLA vs SLO vs SLI — turning a measurement into an internal target and a customer promise.
Error budgets explained — how much failure your target actually permits, and what to do when it is spent.
What is MTTR? — measuring recovery once something has gone wrong.
Why uptime percentage alone is misleading — why a single availability number hides the distribution.

Next steps

Run a one-off speed test — see the timing breakdown for your own URL from 28 regions, no account needed.
Create your first monitor — start tracking these metrics.
Understanding uptime monitoring — broader monitoring concepts.
HTTP monitor reference — technical specifications.