Uptime
TCP check
TCP check is a probe that tries to open a socket on a host and port and passes if the connection is accepted. It does not speak the application protocol.
How it is measured
The probe sends SYN and waits for SYN-ACK within a timeout, for example 3 seconds. Record connect time. A time that creeps from 20 ms to 800 ms means a saturated listener or a firewall drop.
Use it where HTTP does not apply: databases on 5432, Redis on 6379, SMTP on 25 or 587, SSH on 22, or a game server port. Check from the network position your clients use.
Worked example
A Postgres host serving a WordPress network is checked on port 5432 every 30 seconds. At 22:10 the postmaster is hung at its connection limit. TCP connects succeed in 12 ms, since the OS accepts them while the server is wedged, but queries time out.
The TCP check stays green and the HTTP check fails. That mismatch tells the team the network and port are fine and the process is not answering. A follow-up query check with SELECT 1 closes the gap.
How it differs
TCP check verifies a port accepts a connection. HTTP check verifies a web response. TCP excludes status and content, so a dead app behind an open port passes. HTTP excludes non-web services.
Common errors
Treating an open port as a healthy service. Checking from inside the same subnet. Leaving database ports open to the world for monitoring. Using short timeouts on slow links. Checking a load balancer's port instead of the backends.
In practice
Use TCP checks for ports with no HTTP interface and pair each with a protocol-level check where you can, such as a SELECT 1 or an SMTP banner. Restrict access to the probe source IPs.