HTTP, TCP, DNS, SSL, what each check really tells you
Most uptime monitoring comes down to a handful of check types, and teams often reach for the wrong one. They run an HTTP check and assume it covers everything, or they run a ping and call it monitoring. Each check answers a different question, and knowing which question you are asking is the difference between real coverage and a false sense of it.
This is what each of the four basic checks actually tells you.
HTTP, is the application responding correctly
An HTTP check asks for a page or an endpoint and looks at what comes back. The status code, the response time, and optionally whether the content is what you expect. This is the closest to what a user experiences, because it exercises the whole stack. If you run one check, this is usually the one.
TCP, is the port even open
A TCP check just asks whether a service is accepting connections on a port. It does not care about content. It is the right tool for things that are not web pages, a database, an SSH server, a mail server, anything that listens on a port. If the port is closed, you know the service is down before any higher-level check matters.
DNS, can users find you at all
A DNS check verifies that your names resolve to the right place. It catches a whole class of outages where the servers are healthy but nobody can reach them because resolution broke. Servers up, users locked out, and only a DNS check sees it.
SSL, is your certificate still valid
An SSL check watches certificate expiry and validity. It is the one that prevents the self-inflicted outage where a certificate lapses and every browser blocks your site overnight. It runs slow and steady, because the thing it watches changes on a calendar, not by the second.
Use them together
No single check covers a service. Vigiles runs all four, from multiple locations, so you can ask every one of those questions about the same endpoint and actually know it is healthy, not just that one layer of it answered. Start free, or see where we monitor from.