TCP port monitoring for databases, mail servers and SSH

What a completed handshake proves

A port monitor connects to host:port over TCP and succeeds the moment the three-way handshake finishes. The time that took is stored as the response time, and the socket is closed at once without sending data. That is proof that something accepted the connection, no more. It does not prove that the service behind the port is healthy, that authentication works, or that a query would return rows. A database that accepts connections but is stuck on every query still passes this check.

Be aware that load balancers, reverse proxies and some CDNs accept connections on behalf of a backend that may be dead. If the port you probe terminates at a proxy, the monitor tells you about the proxy. Probe a port on the real machine when you need to know about the real machine.

Refused, timed out, or not found

The failure message is a triage tool in itself:

• "Connection refused": the host is alive and reachable, but nothing listens on that port. The service crashed or stopped.
• "Timeout after 10 s connecting to host:port": packets vanish. A firewall drops them, the host is down, or the route is broken. This is also what you see when a security group changes and forgets to allow the checkers.
• "DNS lookup failed": the name does not resolve from the checker, so look at your records before the server.
• "Connection reset" or unreachable messages: a device in the path is actively rejecting or has no route.

Ports people actually monitor

Mail: 25, 465 and 587 for SMTP, 993 for IMAP, 995 for POP. A mail server that stops listening produces silence rather than errors for users, so this is often the only warning. Remote access: 22 for SSH, 3389 for RDP. Databases and caches: 3306 for MySQL, 5432 for PostgreSQL, 6379 for Redis, 27017 for MongoDB, but see the next section before exposing them. Games with a TCP listener, such as Minecraft Java on 25565, are a natural fit as well. For anything that talks UDP, use the UDP monitor instead.

Never open a database to the world for a monitor

The monitor must reach the port from the public internet, which tempts people to expose a database or cache to everyone. Do not. Restrict the rule to the addresses on the checker IP list, which are published for exactly this purpose; a firewall rule that allows only those addresses keeps the port closed to everyone else. If that is still too much, monitor the application's own health URL, which exercises the database from inside, and use the port check only for services that are public by design, such as mail and SSH.

The IP list can change as regions are added, so subscribe to its updates or review the rule when you see unexplained timeouts. A good habit is to name the firewall rule after the monitor, so whoever tidies the rules next year knows that removing it will silence a check and not just clean up a list. For SSH specifically, a restricted source rule plus key-only login keeps the exposure small.

Timeouts, intervals and TLS ports

The default timeout is 30 seconds, but a TCP handshake that takes more than 5 to 10 is already a symptom, so most port monitors benefit from a shorter value. Intervals follow your plan: 5 min on Free, 1 min on Starter, 30 s on Pro and Agency. Port monitoring is on every plan.

On a port that wraps traffic in TLS, 465 or 993 for example, the plain check only shows that the listener exists. Add an SSL monitor with the same port to verify the certificate. There is no send-and-expect feature on the TCP monitor, so you cannot test a banner or a protocol conversation; use an HTTP or keyword monitor where the service has a web interface.