Catching the failures HTTP monitoring can't see.
Port monitoring checks whether a specific TCP or UDP port is open and accepting connections. Learn how it works, when to use it, and how it differs from HTTP monitoring.
Port monitoring (also called TCP port monitoring) is the process of checking whether a specific network port on a server is open and accepting connections. It works at the transport layer (Layer 4) — lower than HTTP — by attempting to establish a TCP connection to a given host and port number.
If the connection succeeds, the port is open and the service behind it is running. If the connection fails or times out, something is wrong: the service has crashed, a firewall rule has changed, or the host is down.
HTTP monitoring tests the full request/response cycle — it sends an HTTP request and checks the status code, response time, and body. Port monitoring only tests whether a TCP connection can be established. It doesn't send any application-layer data.
This makes port monitoring useful for services that don't speak HTTP: databases (port 5432 for PostgreSQL, 3306 for MySQL), mail servers (port 25 for SMTP, 993 for IMAP), SSH (port 22), Redis (port 6379), and any custom application protocol.
Use port monitoring for any service that listens on a TCP port but doesn't expose an HTTP endpoint. Common use cases include databases, mail servers, cache servers, message queues, SSH daemons, and game servers.
Pair port monitoring with HTTP monitoring for complete visibility: port monitoring tells you the service is accepting connections; HTTP monitoring tells you it's responding correctly. A port can be open while the application behind it is returning errors.
SurePing includes this monitor type on every plan — including the free tier.