About
Six lookups that run from our server rather than your machine. That is the whole point of them: they answer what the internet sees, which is often not what your laptop sees, and the difference between the two answers is usually where the problem is.
Why an outside view is the useful one
Testing from inside the network that hosts a service proves very little, because local traffic often bypasses the firewall entirely and your resolver may still hold the record you just changed. A request that starts elsewhere crosses everything a real visitor crosses. When a colleague can reach something and you cannot, comparing your result against this one narrows the problem quickly.
Cache is the usual explanation
DNS changes propagate on a timer that was set before the change was made, so a record can be correct at the registrar and invisible to most of the world for hours. HTTP responses arrive through CDN caches that rewrite headers on the way. Before deciding a configuration is wrong, work out how old the answer in front of you is allowed to be.
Snapshots rather than monitoring
Each of these runs once, when you press the button, and keeps nothing. There is no history, no alert when a certificate approaches expiry, and no repeated probing. That makes them good for answering a question and unsuitable as a watchdog. If a certificate expiry has ever surprised you, the fix is a monitor, not a bookmark to this page.
Reading a failure honestly
A refused connection means something declined it. A timeout usually means a firewall dropped it silently, which looks identical to a host that does not exist. An empty DNS answer can mean the record was never created or that a resolver failed. None of these tools guess between those cases, and the specific words in a result are chosen so you can tell which one you got.
FAQ
Why does this disagree with my own machine?
Different vantage point. Your resolver has a cache, your network has its own rules, and CDNs answer differently by region. Both answers can be correct at once.
Can I check hosts I do not own?
Reading public DNS, headers and certificates is fine, since those are published to anyone. Port checks belong on infrastructure you are responsible for, and nothing here scans ranges or repeats on a schedule.
Which address does the public IP page show?
The one our server saw on your connection, which is what every site you visit sees. It is not the private address your router assigned you.
Related tools
Look up DNS records, see your public IP, test a TCP port, read HTTP response headers and check an SSL certificate, all from a public vantage point.