TCP monitoring: is the service still accepting connections?

Why a handshake is a useful, narrow signal

A TCP monitor does one thing: it resolves the hostname, refuses private addresses, opens a connection to the port you chose and stops the clock when the handshake completes. It sends no bytes afterwards and reads nothing back. That makes it equally valid for a mail server, a database, a game server or an SSH bastion, because none of them need to be spoken to in their own language.

The narrowness is also the limit. A database that accepts connections but is stuck replaying its log still passes. Treat a TCP check as the first line, "something is listening", and add a higher-level check where one exists: an HTTP check for a web app, a keyword check for a page that must render, a DNS check for a name server.

Ports people monitor, and what a failure usually means

The same three outcomes appear on every port, and they point in different directions. Use the table of causes below as a starting order for the investigation, not as a verdict.

• Connection refused: the host is up and the service is not listening. The process crashed, was stopped by a deploy, or binds to localhost only after a config change.
• Timeout: nothing came back. Think firewall or security group first, especially after an address change on the checker side (see the checker IP list), then an overloaded host.
• Reset by peer: the service accepted and dropped the connection at once. Connection limits, fail2ban-style rules and rate limiters behave like this.
• Handshake slow but successful: the chart climbs before anything fails. A database host with exhausted backlog slots often looks like this for hours.

Intervals, regions and plans

TCP checks are available on every plan. Free runs them every 5 min, Starter every 1 min, and Pro and Agency every 30 s. A failure is re-checked from the other live regions (2 regions today) before an incident opens, which matters more for TCP than for HTTP: transit trouble between one region and your provider looks exactly like a dead service from that one region.

Exposing a database port to the whole internet just to monitor it is not a good trade. Prefer to monitor the public service in front of it, and use an allow-list that includes the checker addresses only for ports that are meant to be public, such as SMTP.