TCP / port monitor

Monitor any TCP port for reachability — databases, mail servers, SSH, and custom services.

Last updated April 26, 2026

The TCP monitor (shown in the dashboard as Port (TCP)) opens a TCP connection to a host and port on a configurable interval and records whether the connection succeeded and how long it took. Use it for anything that listens on a port but doesn't speak HTTP — databases, message brokers, SSH, SMTP, custom binary protocols.

Overview

Every TCP check records:

Whether the agent could complete a TCP handshake to host:port.
The connection time in milliseconds (DNS + TCP SYN/ACK round-trip).
The error reason on failure (timeout, refused, host unreachable, etc).

A check is up when the three-way handshake completes within the timeout, and down otherwise. The TCP monitor does not read or send any application-level bytes — that's HTTP's job. If a process is bound to the port but stuck or wedged, the TCP check will still report up. Pair it with an HTTP monitor when you need L7 health.

Configuration options

Host — Hostname or IP address. DNS is resolved on every check.
Port — TCP port to connect to (1–65535).
Interval — How often to run the check (default: 60 seconds).
Timeout — Mark as down if no SYN/ACK within N seconds (default: 3s).
Regions — Which monitoring regions run the check. See Multi-region checks.

When to use TCP vs HTTP

Scenario	Monitor type
Web service (`/health` returns 200)	HTTP
Database accepting connections (Postgres, MySQL, Redis, Mongo)	TCP
Mail server, SSH, FTP	TCP
Custom TCP protocol (binary, line-based)	TCP
Anything where you need to assert on response body	HTTP
Anything where you need an application-level health signal	HTTP

If both are useful — for example, a Postgres server that you also expose via PgBouncer on a separate port — create two monitors.

Common ports cheat-sheet

Service	Port
SSH	22
SMTP	25, 587
HTTP / HTTPS	80 / 443
MySQL	3306
PostgreSQL	5432
Redis	6379
MongoDB	27017
RDP	3389
IMAPS	993
LDAPS	636

Example

You run a Postgres replica on db-replica-1.internal:5432. Create a TCP monitor with:

text

Type:     Port (TCP)
Host:     db-replica-1.internal
Port:     5432
Interval: 60s
Timeout:  3s

If the replica goes down or its security group changes, you'll get a down alert within one interval.

Firewalls and security groups

A TCP monitor only verifies that the port is reachable from the monitoring agent's network path. If your service is behind a private network or firewall, use a dedicated monitoring node inside the same network — see the dedicated-node setup in your dashboard.

TLS handshake

A plain TCP monitor stops at the TCP handshake — it does not negotiate TLS. To verify that a TLS service is presenting a valid certificate, use the SSL & domain expiry monitor instead, which is specifically designed for cert validation and expiry tracking.

Limitations

No application-level assertions (no banner matching, no EHLO/STARTTLS probing).
Connection refused is treated as down even if it's the expected behavior for the service. If your service intentionally rejects connections from non-allowlisted IPs, expect false alerts and either allowlist the monitoring agent's IPs or use a dedicated node inside your network.
No port-knocking sequences or multi-stage handshakes.