DNS
Resolving the name. Paid once and then cached, so it affects the first visit rather than every one — but a slow authoritative nameserver shows up here.
A single "2.4 seconds" tells you nothing actionable. Knowing that 1.9 of it was DNS, or the TLS handshake, or the server thinking, tells you where to look — so each phase is timed on its own connection rather than estimated from the total.
Resolving the name. Paid once and then cached, so it affects the first visit rather than every one — but a slow authoritative nameserver shows up here.
The round trip to open the connection. Almost entirely distance and routing; nothing about your server changes it.
Negotiating encryption. TLS 1.3 needs one round trip where 1.2 needs two, so a slow figure here often just means 1.2.
The server receiving the request and producing an answer. This is the part your application controls.
It can tell you the server is up and answering, how quickly it answers us, and roughly where the time goes. If the response phase is slow, that is your application or database, and it will be slow for everyone. If the connect phase is slow, that is the network path between our server and yours, and it says little about anyone else's path.
It cannot tell you how the site feels to a visitor somewhere else. Their DNS resolver, their route, their distance and their device are all different. The honest version of a global measurement needs probe nodes in each region, which is paid infrastructure — so rather than imply we have it, this page says it measured from one place.
It also cannot tell you about uptime. One request at one moment is not availability; availability is a measurement over time from several places, which is what a monitoring service is for. If the question is "is my site down right now", this answers it. If the question is "how often is my site down", this is the wrong tool and no single-request checker is the right one.
A practical note on redirect chains: each hop is a full round trip before anything renders. Redirecting HTTP to HTTPS and then non-www to www as two separate steps is extremely common and almost always collapsible into one, which is a free improvement to every first visit.
Compare the phases. If the response phase is slow here and fast for you, the likely answers are a cache that has your pages warm and not ours, geography, or a first-request cost — some stacks compile or connect lazily and the first visitor after an idle period pays for it. If every phase is slow, the path between us is the difference.
It checks whether your site answered us just now, which is the useful answer to 'is it down right now'. It is not an uptime monitor: that needs repeated checks from several places over time, and a single request cannot substitute for it.
Because they overlap. The request-and-response figure is the whole exchange including the connection it had to make, so it contains the connect and TLS time again. They are shown separately because each one isolates a different cause, not as a breakdown of a whole.
A firewall or bot-protection service is refusing our request specifically. That is the protection working as configured, and it means the result says nothing about the site itself. It is worth knowing if you also use an external monitoring service, which will be refused the same way.
Under 200 ms for the response phase on a dynamic page is good, under 500 ms is acceptable, and above a second is worth investigating. Those are rules of thumb, not standards — a page assembling data from six systems has different expectations from a cached one.
A site that answers slowly at 3pm, a certificate that expires on a Sunday, a redirect chain that grew a hop nobody noticed. We monitor and operate infrastructure around the clock, which is the difference between knowing and being told by a customer.