TCP port monitors

A TCP port monitor opens a network connection to one specific port on the target and counts the check as up if the connection is accepted within the 10-second timeout. Choosing the TCP port check type reveals the Port field, which takes any port from 1 to 65535; the recorded response time is how long the connection took to establish. (For what happens on the wire, see how TCP checks work.)

This is the check for services that aren't websites: things with no URL to request, but a port that must be listening for the service to exist at all.

Typical services worth a TCP monitor

On 443: for websites, an HTTP monitor is almost always the better choice — it judges status codes and watches the TLS certificate. Reserve a bare TCP check on 443 for HTTPS services that aren't web pages, or endpoints where every URL demands authentication.

What a successful connect proves

An accepted connection establishes three things at once:

• The host is reachable over the network.
• No firewall along the path is blocking that port.
• A process is actually listening on the port and accepted the connection.

That's strictly more than a ping proves — ping says the machine is there, a TCP connect says the service is there. It's also less than a full transaction proves: the check doesn't speak the application's protocol, so a database that accepts connections but fails every query still counts as up. In practice that gap rarely bites, because the dominant failure modes — the process died, the service crashed on boot, someone changed a firewall rule — all stop the port from accepting connections, and the check catches every one of them.

When to choose TCP over the alternatives

• The service isn't HTTP. Mail, databases, and RDP have no meaningful URL; TCP is the natural probe.
• ICMP is blocked. Networks that drop ping can make a healthy host look down; a TCP check against a known-open port measures reachability through firewalls that permit the service. See Ping monitors.
• You want the service, not the host. A server can answer ping while its mail daemon is dead. Monitoring port 25 alarms on what clients actually feel.

Everything else behaves as with any monitor: the interval and failure streak decide when an incident opens, the degraded threshold (up to 9999 ms for TCP) marks slow connection times as amber, and Test connection probes the exact host-and-port pair before you save — see Test connection.