EnterraHost
A server check makes one request from outside a site and reports what came back. It is the fastest way to answer the questions that usually start a support ticket, including server response time, and it answers four of them at once rather than one at a time.
You can run one against any hostname without an account. This is what each part of the result means and what it cannot see.
The four answers it gives first
- Does it answer. The status code and whether a connection completed at all. This is the one line that separates a site that is down from a site that is up and wrong.
- How fast. The time taken to connect and the time taken for the server to respond, separated. Those are different problems with different owners. A slow connect is a network or a host problem. A slow response after connecting is the application.
- Is the certificate sound. Whether a certificate was presented, which version of TLS carried it, and when it expires. Checking a TLS certificate covers that part in detail, because there is more to it than a padlock.
- Which address family works. Whether the name resolves to IPv4, IPv6 or both, and whether both answer. A published IPv6 address that nothing can reach is a common and quiet failure. The IPv6 test covers the client side of that.
It runs from the region you choose
The check is made from a region you pick, and that choice is part of the result. A site behind a CDN is answered by the nearest edge, so the same hostname measured from St Louis and from Singapore can report different networks, different countries and different times. The region selector is how you see what a visitor in that part of the world sees.
What it says about the server
The response headers usually name the web server software and often the language runtime behind it. That is useful for two reasons. It tells you what you are dealing with when you have inherited a site, and it tells you what you are advertising, because a version number in a header is information you did not have to give away.
The check also reports whether a content delivery network is in front of the site. The next section is why that field is easy to over-read.
What the response headers say
The headers are where a check like this earns its keep, because they are the server describing itself rather than a lookup describing a registration. Two tables come back. The first lists the security headers it looks for and whether each one was sent, which is the quicker read of the two.
The second is the raw list, which answers different questions. A caching header tells you whether the copy you received came from an origin or an edge, an age header tells you how long that copy has been held, and a server timing or protocol header tells you what answered.
What it says about the address
The result gives the IP address, the network it belongs to, the autonomous system number, and the country the network is registered in.
The country is the network's registration, not the machine's location. A server can sit in one country and be announced by a network registered in another. Treat the country as a clue about who operates the address rather than where the hardware is. It is the single most over-read field in any check like this.
Behind a CDN, every one of these fields describes the edge rather than the origin. The IP belongs to the CDN, the network belongs to the CDN, and the country is wherever that edge happens to be. That is not a fault in the check. It is the check telling you the truth about what the public internet sees.
What it says about the domain
Two fields come from the domain registration rather than from the site. The registrar is who the name is registered through, and the expiry date is when it lapses.
Expiry is worth watching because it is the one failure that takes everything down at once and cannot be fixed after the fact. A domain that lapses stops resolving, which means the site, the email on that domain and every link to it stop working together. If a check shows a date inside the next few weeks, that is the finding.
What it says about DNS
The check reports the addresses the name currently resolves to, separately for IPv4 and IPv6. Reading those against what you expect is how you catch a stale record, a migration that only half finished, or a name pointing at an old host.
It also tells you whether the two families are both published. A site with only an IPv4 record is invisible to the growing share of connections that prefer IPv6 when it is offered.
What an outside check cannot see
Three limits are worth knowing before you draw a conclusion.
A CDN hides the origin. You are checking the edge, so you learn nothing about the machine serving the pages unless you query it directly.
A blocking firewall looks exactly like a failure. Some hosts drop requests from unfamiliar networks on purpose, and a check run from a datacenter is unfamiliar by definition. If a site answers in your browser and not in the check, suspect a block before you suspect an outage.
Nothing inside the server is visible. Load, memory, disk, database health and application errors are all invisible from outside, and a check that returns a fast, correct response is not evidence that the machine behind it is healthy.
When server response time is fine but the page still feels slow
A fast server response and a slow page are not a contradiction. The check measures the time until the first byte arrives from the server. Everything after that happens in the browser, and on a slow connection or a heavy page it is most of the wait.
That is where the measurement stops being the whole story. A response time of 200 milliseconds with a page that takes four seconds to become usable means the problem is on the page rather than on the server, and the other tools here cover the parts that come after this one.