Hesklo
Home/Features/TCP monitoring
TCP monitoring

Confirm the port is actually open.

Hesklo opens a connection to a host and port and reports whether it was accepted. It is the right check for anything that listens but does not speak HTTP: a database, a cache, a message broker, a mail server.

  • No protocol required. You do not need credentials or a query. If the service accepts a connection, it is listening.
  • Works where ICMP is blocked. Many networks drop ping but allow traffic to a specific port. TCP checks get through where ping cannot.
  • Connect time recorded. Every check stores how long the handshake took, which surfaces a saturated service before it refuses connections outright.
01 · What to point it at

Anything that listens on a port.

A TCP check is deliberately shallow. It tells you the service is up and accepting work, which for most infrastructure is the question that matters.

Databases

Postgres, MySQL, MongoDB and anything else that binds a port. Know it is accepting connections before your application finds out.

Caches and brokers

Redis, Memcached, RabbitMQ, Kafka. Services that rarely have a health endpoint but always have a port.

Mail servers

SMTP, IMAP and submission ports, checked the same way a client would reach them.

Internal services

Anything behind your own network that speaks a custom protocol. No parser needed, just a successful connection.

SSH availability

Confirm port 22 is reachable as a lightweight precursor to a full SSH diagnostic check.

Load balancer backends

Check individual backends directly, so you see a single node fail even while the pool still serves traffic.

02 · How it behaves

Tuned so a real failure gets through.

Custom timeout

Decide how long to wait for the handshake. A service under load may be slow without being down.

Confirm before paging

Require several refused connections in a row before the monitor counts as down.

Run a check now

Test the port on demand and see the exact result, without waiting for the next scheduled run.

Maintenance windows

Pause during planned work so a known restart pages nobody, then resume automatically.

Questions

Common questions

Does a TCP check verify the service is working correctly?
It verifies the service is accepting connections, which is a strong signal but not a full health check. For a service that speaks HTTP, an HTTP monitor tells you more because it can match a status code or a string in the response body. TCP is the right tool when there is no HTTP endpoint to check.
Can I monitor a database without giving Hesklo credentials?
Yes, and that is the usual setup. A TCP check only opens a connection to the port. It never authenticates, sends a query or reads any data, so there are no database credentials to store or rotate.
Should I use TCP or ping?
Ping tells you the machine is on the network. TCP tells you a specific service on that machine is listening. If your firewall blocks ICMP, TCP is also the only one of the two that will work.
Can I monitor an internal service that is not on the public internet?
The host and port need to be reachable from where the check runs. For internal-only services, teams commonly expose the port to a restricted source range or run the check against a reachable jump point.
Keep reading

Related features

Watch the ports that matter.

Three monitors are free forever. Add a TCP check and draw what happens when the connection is refused.