TCP port monitoring for everything that is not a website

What a TCP check tells you

The probe opens a TCP connection to a host and port, waits up to the monitor timeout, and closes it again. A completed handshake passes. A refusal, a timeout, or an unresolvable name fails, reported with the underlying reason and the elapsed time. In other words: is anything listening on that port right now?

That is a narrow question, deliberately. It does not log into your database or send an EHLO. What it proves is the layer that fails most often: the process is running, it is bound to the interface you think it is, the port is open on the firewall, and a route from the outside exists.

It is also the right check when the target speaks TLS but cannot be checked that way. An internal service behind a self-signed certificate would fail an SSL monitor by design; a TCP monitor on the same port still proves the listener is alive.

Things worth pointing it at

• Databases: Postgres on 5432, MySQL on 3306, Redis on 6379, MongoDB on 27017. A managed database that fails over shows up here first.
• Mail: SMTP on 25 or 587, submission on 465, IMAP on 993. A mail server that stops accepting connections stops accepting your customers' replies.
• Remote access: SSH on 22, RDP on 3389, a WireGuard endpoint. Learning the jump host is gone beats learning it mid-incident.
• Game servers: Minecraft on 25565, a source engine server, an RCON port.
• Message brokers: MQTT on 1883 or 8883, RabbitMQ on 5672, Kafka on 9092.
• Anything on a strange port: an admin panel behind a reverse proxy, a device that only speaks its own protocol.

Targets, ports, and IPv6

The target field is flexible about form. Write host and port together as db.example.com:5432, or write the host alone and set the port in the monitor configuration. A scheme prefix is stripped if you paste one. Bare IPv6 literals are parsed correctly rather than mangled by colon splitting, and [2001:db8::1]:5432 works as expected.

The probe resolves the hostname, validates the address, and connects to that validated address rather than re-resolving at connect time, which closes a rebinding gap. The consequence is that targets must be publicly reachable: private and internal addresses are refused. For internal services, a heartbeat monitor pushed from inside your network is the pattern that works.

TCP monitors record the connect time and chart it like any other latency series. That number is more useful than it sounds: a database whose connect time climbs from 12ms to 900ms over a week is telling you something before it starts refusing connections.

Confirmation, incidents, and alerts

Like every type, a TCP check does not page anyone on a single bad result. Two consecutive failures mark the monitor down by default and one success clears it, both adjustable. That matters more here than for HTTP, because connection attempts across the open internet fail transiently.

Once confirmed, an incident opens by itself carrying the connection error as the detected cause, and resolves itself when the port comes back, with the recovery alert reporting how long it was out. Both transitions travel to email, ntfy, Telegram, Slack, Discord, and generic webhooks, all on every plan including free, with exactly-once delivery per transition per channel, so a service restarting under load cannot bury you in duplicate pages.

Setting up a TCP monitor

• Create a monitor and choose the TCP port type.
• Enter the target as host:port, or enter the host and set the port field separately as a fallback.
• Set a timeout that suits the service. The 15-second default is generous for most listeners.
• Adjust the failure threshold if the path to the target is known to be flaky.
• Pick an interval: five minutes on the free plan, one minute on Pro, on a fixed minute grid.
• Attach notification channels, or leave it unrouted so every team channel hears about it.

The free plan carries ten monitors permanently, with 30 days of history, a public status page, and every alert channel. Pro is a flat price for the entire team with no per-seat or per-monitor charge: 50 monitors, one-minute checks, a year of history, unlimited status pages and members, and custom domains, after a 14-day Pro trial with no card.

Questions people ask