Most monitoring setups answer exactly one question: is the website returning a 200? That check has become the default because it’s easy to reason about and easy to wire into an alert. It also happens to be the equivalent of standing across the street and asking, “can you see the building?” You can confirm the structure is there. You learn nothing about whether the doors are locked, whether the plumbing still works, or whether the road that leads to it has been quietly rerouted overnight.
The trouble is that HTTP operates near the top of the stack, and a whole category of failures lives below it. DNS can resolve to the wrong address while your availability check sails through. A TCP service can stop accepting new connections while a cached homepage still loads fine for the synthetic probe. Reachability can degrade in one region while another stays perfectly healthy, and an HTTP check pointed at a single endpoint will never notice. These aren’t exotic edge cases but ordinary network-layer problems that an application-layer check is structurally blind to, and three lower-level checks close most of that gap.
CONTENTS
DNS: watching which site is actually up
A successful HTTP response tells you a site is up. It does not tell you which site. Those are different statements, and the difference is exactly where a lot of incidents hide. If a domain has been pointed somewhere it shouldn’t be — through registrar compromise, a hijacked zone, or a record someone changed without telling anyone — your probe will still resolve a name, still open a connection, and still get its 200 back. The check passes. The answer to “where did that name resolve?” has quietly changed underneath it.
It helps to remember what resolution actually does before you decide what to watch. DNS is the system that turns a human-readable name into the address a machine can route to, walking from root to TLD to authoritative server, and Cloudflare’s DNS Learning Center lays out that chain clearly if you want the full mechanics. Every link in that chain is something that can be tampered with or simply misconfigured, and most of it is invisible from the application layer.
Watching DNS as its own signal catches the class of problem an availability check never sees. A TTL that suddenly drops ahead of a planned cutover, an A record that now points at an IP you don’t recognize, an NS delegation that changed without a corresponding ticket — each of these is worth an alert on its own merits. Dangling CNAME records deserve special attention, because a CNAME pointing at a deprovisioned cloud resource is the setup for a subdomain takeover, and nothing about a healthy homepage will warn you it exists. For anything customer-facing, DNS earns its own watch rather than the assumption that a green HTTP check implies healthy infrastructure.
TCP: confirming the service still answers
The next layer down asks a narrower, sharper question: is the service actually accepting connections right now? A TCP port check answers that without involving the application at all. It opens a connection — SYN out, SYN-ACK back, ACK to finish — and the completed handshake is proof that something is listening on that port and willing to talk, with no request body, no response parsing, and no waiting on the application to render a page. It’s confirmation that the door opens when you knock, and nothing more.
That narrowness is the point. Plenty of failures show up as a port that has stopped listening while everything above it looks fine. A backend process crashes and the socket closes. A firewall rule gets edited and now silently drops traffic to 5432 or 6379 while leaving 443 alone. A connection pool exhausts and new handshakes hang half-open, never completing. An HTTP check aimed at the public homepage can pass through a CDN cache during every one of these, telling you nothing is wrong while a critical dependency is, in fact, unreachable. Watching the specific ports your services depend on closes that blind spot directly.
Knowing which ports to watch is its own small discipline. The well-known assignments are standard (22 for SSH, 53 for DNS, 5432 for PostgreSQL), but the useful habit is to monitor the ports that carry your actual dependencies, not just 80 and 443. A database, a message broker, or an internal API that stops accepting connections is an outage in the making, and a TCP check sees it coming long before the symptom surfaces in a user-facing request.
ICMP: spotting trouble underneath the connection
Below TCP sits ICMP, the protocol the network uses to talk about itself — reachability, errors, and the diagnostics thatpingandtracerouteare built on. Its behavior was specified back in RFC 792, and it remains the cleanest way to ask whether a host is reachable at all and how the path to it is behaving. Because it lives beneath the transport layer, it surfaces problems that a TCP check can mask.
Consider a server that’s quietly dropping a meaningful fraction of packets at the network layer. A TCP handshake might still complete — retransmissions paper over the loss — so a port check comes back green, just slower than usual. Underneath that “success” is a path shedding packets and a latency baseline creeping upward, the early signature of congestion, a failing link, or a saturated upstream. ICMP makes that visible as packet loss and rising round-trip times before it hardens into a connection failure your other checks would finally register.
The value here is trend as much as state. A single ping that succeeds tells you very little. A baseline of round-trip times and loss percentages, watched over days, tells you when a path is degrading well ahead of the point where users start complaining. Reachability and latency are the foundation the higher-layer checks quietly assume, and measuring them directly means you stop taking that foundation on faith.
One vantage point is one blind spot
Every check above shares a weakness if you only run it from a single place. A probe sitting in one datacenter has the same limitation as a security camera pointed at one door: it reports faithfully on what it can see and stays silent about everything it can’t. Networks fail in ways that are deeply local. A routing change at one transit provider, an ISP-specific outage, a misbehaving CDN edge node, a regional resolver returning a stale or poisoned answer — each of these can break the experience for a large set of users while your single probe, sitting on a healthy path, insists everything is fine.
The inverse is just as misleading. One probe with a bad local route looks identical to a real outage, and acting on that false signal erodes trust in the monitoring itself. The fix in both directions is the same: test the same target from several geographic locations and reconcile the results. When checks from multiple regions agree, you can trust the verdict. When they disagree, the disagreement is the finding — it tells you the problem is regional, often the single most useful fact in the first minutes of an incident.
Putting the layers together
Run on their own, these checks are useful. Run together and from several places, they describe network health with a completeness that no HTTP check approaches. DNS confirms names resolve where they should. TCP confirms the services behind those names are accepting connections. ICMP confirms the paths to them are healthy and stable. Multi-region execution confirms all of that holds for users who aren’t sitting in your home datacenter.
Standing this up by hand is entirely possible —digon a schedule, scripted port probes, apingloop feeding a time-series database, cron tying it all together. It works, but you become responsible for the probes, the storage, and the reconciliation across regions. Rather than scripting separate checks, an external network monitoring service can run DNS, TCP, and ICMP checks from multiple geographic regions and reconcile the results into a single view. Either path gets you to the same place. The question is only how much monitoring infrastructure you want to maintain yourself.
Conclusion
An HTTP 200 is a fine answer to a single, narrow question, and it will keep its place at the front of most monitoring setups. The mistake is treating that one answer as the whole picture. DNS, TCP, and ICMP each watch a layer the availability check can’t reach, and together they catch the hijacked record, the port that stopped listening, and the path that’s silently shedding packets — the failures that load a cached homepage just fine while something real is broken underneath. Run them from more than one place, and you trade a single point of view for an actual map of how your infrastructure looks from the outside.
Hey, I’m Jeremy Clifford. I hold a bachelor’s degree in information systems, and I’m a certified network specialist. I worked for several internet providers in LA, San Francisco, Sacramento, and Seattle over the past 21 years.
I worked as a customer service operator, field technician, network engineer, and network specialist. During my career in networking, I’ve come across numerous modems, gateways, routers, and other networking hardware. I’ve installed network equipment, fixed it, designed and administrated networks, etc.
Networking is my passion, and I’m eager to share everything I know with you. On this website, you can read my modem and router reviews, as well as various how-to guides designed to help you solve your network problems. I want to liberate you from the fear that most users feel when they have to deal with modem and router settings.
My favorite free-time activities are gaming, movie-watching, and cooking. I also enjoy fishing, although I’m not good at it. What I’m good at is annoying David when we are fishing together. Apparently, you’re not supposed to talk or laugh while fishing – it scares the fishes.