TCP port monitoring
for everything that isn't HTTP
Databases, message brokers, SSH, SMTP, custom socket services — anything that listens on a port. Status Harbor confirms the handshake completes every minute, from 9 regions, and alerts the moment a port stops answering.
When an HTTP check has nothing to check
Most of your stack does not speak HTTP. Postgres, Redis, Kafka, RabbitMQ, SSH, an SMTP relay, a game server, an internal gRPC service on a raw port — none of them return a status code you can inspect. An HTTP monitor pointed at port 5432 gets a connection, then garbage, then a timeout.
For these services the right question is simpler: is the port open and accepting connections? A TCP monitor answers exactly that, without needing to understand the protocol on top.
What a TCP monitor confirms
- Connect success — the monitor opens a TCP connection to the host and port. A completed handshake means the service is listening and reachable.
- Handshake validity — a refused connection, a timeout or a reset is a distinct failure, so the alert tells you whether the port is closed, filtered or slow.
- Multi-region confirmation — probe from up to 9 regions. A failure from one region is a network path issue; a failure from all of them is the service. The alert says which.
Common TCP monitoring targets
Databases (Postgres, MySQL, MongoDB), caches (Redis, Memcached), message brokers (Kafka, RabbitMQ, NATS), SSH on a bastion, an SMTP relay, and any custom service on a raw socket. If it accepts a TCP connection, a TCP monitor can watch it.
Many of these run inside a private network. Pair a TCP monitor with a Lighthouse agent and you can watch an internal database or broker the same way you watch a public port — the agent connects from inside, with no inbound ports to open. Read more about private network monitoring.
Frequently asked questions
What does a TCP monitor actually check?
It opens a TCP connection to a host and port and confirms the handshake completes. A successful connect means the service is listening and reachable on that port. No application data is sent, so it works for any service that accepts TCP, regardless of protocol.
When should I use TCP monitoring instead of HTTP?
Use HTTP for anything that serves HTTP — it inspects status code and body. Use TCP for everything else: databases, message brokers, SSH, SMTP, custom socket services. For those, a completed handshake is sufficient proof the service is up.
Can it monitor a database or message broker behind a firewall?
Yes. Run a Lighthouse agent inside the network and point a TCP monitor at the private host and port. The agent connects from inside and reports over a single outbound HTTPS connection — no inbound ports, no VPN.
How fast does it detect a port going down?
TCP monitors run every minute from up to 9 regions. A port that stops accepting connections is detected within a minute, and multi-region confirmation rules out a single bad network path before an alert fires.
Related
- DNS monitoring — confirm the hostname your TCP target resolves to is correct.
- SSL certificate monitoring — for TCP services that terminate TLS, watch the certificate too.
- On-prem monitoring — monitor internal databases and brokers cloud tools can't reach.