TCP and Ping monitoring

A lot of what keeps a site running isn't the site itself. A database, a mail server, a queue passing messages between two applications: services living below the surface, invisible to anyone who isn't looking in exactly the right place, and completely out of reach for an HTTP check.

What it actually checks

The TCP monitor opens a real connection to the host and port you specify, and measures how long it takes to respond. No scanning, no arbitrary payloads: just the port you chose, always within the allowlist your package permits, so it never turns into a tool for poking around where it shouldn't. The Ping monitor works at an even more basic level, checking whether the host is simply reachable on the network, before any question of specific ports or services comes into play.

A concrete case

Your own personal project

You built a booking app for your dental practice, small but real, that talks to a database on a dedicated port. A server update changes a firewall rule and that port stops answering. The storefront in front of it stays perfectly online, so an HTTP check wouldn't see anything wrong, and you only find out when a patient calls the front desk because they can't book an appointment.

A whole client roster's infrastructure

Every client you manage probably has, behind the site the public sees, one or two services like this: a database, a queue, a dedicated mail server. None of them ever come up in a conversation with the client until they break, and that's exactly when you'd rather already know, instead of finding out from a support ticket written in all caps.

A layer that's often missing

Most monitoring tools stop at the web page. Adding a TCP or Ping check alongside your HTTP monitors covers exactly the part that's left exposed, the infrastructure with no interface to glance at but that, if it stops, takes everything else down with it.