Beyond HTTP: monitoring the ports and services your users never see

Most monitoring conversations start and end with HTTP: is the website up, does the API return 200. But the website is just the part users see. Behind it sits a stack of services speaking entirely different protocols — a database on 5432, an SMTP server on 587, an SSH daemon on 22, a game or chat backend on some custom TCP port. None of them answer HTTP requests, and all of them can fail in ways your website check will never notice until it’s too late.

Watching those layers takes two humble, decades-old tools: ping and port checks.

Ping: is the host even alive?

A ping (ICMP echo) is the most basic health question you can ask: is this machine reachable on the network at all? You send an echo request; a healthy host echoes back. From that round trip you learn two useful things:

• Reachability — the host is up and routable, or it isn’t.
• Latency and packet loss — how long the round trip takes, and whether replies are going missing. Rising latency or intermittent loss is often the first tremor before a bigger failure.

Ping is the widest, cheapest net you can cast. It won’t tell you an application is working — only that the machine is on the network and responding. That’s a floor, not a ceiling, but it’s a floor worth watching, especially for routers, gateways, and infrastructure hosts that don’t serve web traffic at all.

Port checks: is the service actually listening?

A host can answer ping while the service you care about is stone dead. The database process crashed, but the server it runs on is fine — ping says “up,” and your app is throwing connection errors. To catch that, you check the port.

A TCP port check attempts to open a connection to a specific port and confirms something is listening and accepting connections:

check tcp  db.internal:5432     # PostgreSQL — is the database accepting connections?
check tcp  mail.example.com:587 # SMTP submission — can we still send mail?
check tcp  example.com:22       # SSH — is remote access alive?
check tcp  game.example.com:7777# custom backend — is the service up?

This is the right tool for anything that speaks TCP but not HTTP. Some common ports worth watching:

• 5432 / 3306 — PostgreSQL / MySQL databases
• 587 / 465 / 25 — mail submission and transport
• 22 — SSH
• 6379 — Redis
• 53 — DNS
• Any custom application port your product depends on

A port check answers a sharper question than ping: not “is the machine alive?” but “is the specific service my users depend on accepting connections right now?”

The layers, and what catches each

Think of it as a ladder, each rung catching failures the one below can’t see:

1. Ping — the host is on the network.
2. Port — the service is listening and accepting connections.
3. HTTP — the web layer responds.
4. API assertions — the response is actually correct.

A website check only covers the top of that ladder. If your database, mail, or backend services matter — and they almost always do — you need the lower rungs too. The database that stops accepting connections at 2am doesn’t return an HTTP error; it just quietly refuses connections until something checks its port.

Where this matters most

Port and ping monitoring earns its keep for the infrastructure that has no web face:

• Databases whose downtime surfaces only as vague app errors.
• Mail servers — you often discover SMTP is down when someone asks why the password-reset email never arrived.
• Game servers, IoT gateways, and custom TCP backends with no HTTP endpoint to poll.
• Internal services and VPN gateways users depend on indirectly.

The bottom line

HTTP monitoring watches the storefront. Ping and port checks watch the warehouse, the loading dock, and the power supply behind it. Layer them — host reachable, service listening, web responding, response correct — and you catch failures at the level where they actually happen, instead of waiting for them to bubble up as a mysterious error on the website. The services your users never see are exactly the ones worth watching directly.

Watch every layer, not just the web page. Explore port & ping monitoring →