EnterraHost
A latency alert means a check took longer than the threshold you have set. It does not mean your site is slow, and the difference is worth understanding before you act on one.
What was measured
Each check records how long the request took, from the monitor’s region to your server and back. That number contains the network path, the TLS handshake if it is a fresh connection, the server’s own processing time, and the time to transfer the response.
Only one of those is your application. A single latency alert does not tell you which part moved, and treating it as a verdict on your code is how a routing problem gets chased through an application that was never at fault.
Why one slow check is not a problem
A single check passing the threshold is normal. Networks are shared, and a route that is 40ms at noon can be 180ms while a transit provider reroutes traffic.
The figures worth looking at are the shape across many checks. A latency that stepped up and stayed up is a change in the path or in the server. A latency that spiked for two checks and returned is a network event, and it will not be there tomorrow.
This is the same reasoning that keeps a short outage out of your incident list. Understanding a downtime event covers the confirmation logic on the availability side.
Separating path from server
If the domain is monitored from one region, a latency alert leaves the question open. From two, it is often answered outright.
A rise seen from Cape Town and not from Frankfurt is a path problem. A rise seen from both is the server. Adding a second region covers setting that up.
Without a second region, the traceroute tool shows every hop between you and the server with a time for each, which usually names the operator where the delay sits. The ping test answers the narrower question of whether the host is reachable and how consistently.
Reading the timing figures in a report
A report gives you more than one number, and they measure different things.
TTFB is time to first byte, which is the server beginning to respond. It covers the network path and the server’s processing, and it is the number to watch when the server itself is suspect.
Load time is the full transfer of the page, so it includes the size of the response as well as the time to produce it. A TTFB that is flat while load time rises is a page-weight problem rather than a server problem.
Page size sits beside them for the same reason. A response that grew by 400KB will show up as a longer load time with nothing else changed.
Which of these moved is what tells you where to look. TTFB above target on enterramon.com deals with the first of them in detail.
When it is worth acting on
Three cases, and they are the ones that repay the effort.
A step change that persists. Something was deployed, a cache was lost, or a route was permanently changed.
A rise that correlates with traffic. The site is slower when more people use it, which is a capacity question rather than a fault.
A rise that appears alongside a rising TTFB and a flat page size. The server is doing more work per request than it used to.
In all three, the alert has done its job by prompting a look. The dashboard and the report are where the answer is, and the alert itself is only a signal that something moved.