What it is
A TCP port monitor opens a connection to a host and port you choose and reports the monitor as up when that connection completes inside the timeout. If you turn on TLS, the handshake has to complete too. That covers Postgres, MySQL, Redis, SMTP, IMAP, SSH, message brokers, game servers, and anything else that listens on a port without serving a web page.
Everything else works exactly as it does for an HTTP monitor. The check runs from all four regions on your chosen interval, response time is recorded per region so the latency charts and history bars are populated the same way, and a state change fires the same alert fan-out: incidents, status page components, subscriber email, Slack, operator email, PagerDuty, and webhooks.
What counts as up
A completed connection, nothing more. realuptime sends no data to the port and reads none back, so a port monitor never speaks your service's protocol, never authenticates, and never touches your data. A refused connection, an unreachable host, or a connection that does not complete inside the timeout marks the region down, and two consecutive failures are required before an incident opens, the same confirmation rule every other monitor type uses.
TLS and certificate expiry
Turning on TLS adds a handshake to the success condition and starts tracking the certificate the server presents. Expiry warnings then work exactly as they do for an HTTPS monitor: you are alerted at 30, 14, 7, and 1 days before the certificate lapses, and the remaining days appear on the monitor in your dashboard.
The up or down result depends on the handshake completing, not on the certificate chaining to a public certificate authority or matching the hostname. That is deliberate. Databases and internal brokers routinely present private or self-signed certificates, and reporting a perfectly healthy database as down because its certificate is signed by your own CA would be a false alarm rather than a useful one. The expiry date is still read and still alerted on, which is the part you actually need to act on.
Choosing a host and port
Enter a bare hostname or IP address, with no scheme and no path, plus a port between 1 and 65535. Targets have to be publicly reachable: private, loopback, link local, and cloud metadata addresses are refused, both when you create the monitor and again every time it runs, so a hostname that later starts resolving to an internal address stops being monitored rather than being probed.
Editing
You can change which regions probe a TCP monitor at any time from the dashboard. The host and port themselves are fixed once the monitor is created: to point at a different service, create a new monitor. This keeps a monitor's history honest, since its recorded uptime always refers to one target.
Availability and pricing
TCP port monitors are available on every plan, free included, and count against the same monitor-slot limit as HTTP and heartbeat monitors. There is no separate allowance and no extra cost. See pricing for what each plan includes.