TCP Port Monitor
The TCP Port Monitor checks whether a raw TCP port is open and accepting connections. It is commonly used for databases, caches, message queues, and other non-HTTP services that don't speak a protocol we have a dedicated monitor for.
How it works
- We attempt to open a TCP connection to your
hostname:port. - If the connection cannot be established or times out, the check fails.
- If you configure Expect Banner, we also verify that the raw bytes received right after the handshake contain that substring (e.g.
+PONGfor Redis,220for an SMTP banner). Otherwise the check fails even though the port is open.
Configuration
Basic settings
- Hostname: Hostname or IP address (no protocol, no path).
- Port: Required. Unlike other monitor types, there is no default port. You must specify the exact port to connect to (e.g.
6379for Redis,5432for PostgreSQL,27017for MongoDB). - Expect Banner: Optional substring the worker must find in the bytes received immediately after the TCP handshake.
- Check interval and Timeout.
- Status:
active,maintenance,disabled.
Monitoring locations
TCP checks run from our monitoring locations. Use Allowed Check Countries to limit where checks run from.
No credentials
TCP Port monitors carry no credentials or authentication. They only verify that the port accepts connections (and optionally that the initial banner matches). For services that require authentication before you can confirm they're healthy, use a protocol-specific monitor (e.g. SSH, SMTP, IMAP/POP) where one exists.
SSH Monitor
The SSH Monitor checks whether your SSH service is reachable. It is commonly used to detect firewall issues, network outages, or server crashes affecting administrative access.
FTP Monitor
The FTP Monitor checks whether your FTP service is reachable and responsive. This helps detect outages on file transfer infrastructure used by legacy integrations, batch exports, or partner uploads.