TCP port monitoring: what it checks and how to use it

What a TCP port check proves

A TCP checker attempts to establish a connection to one public hostname or IP address and one port. It reports UP when the TCP connection succeeds. It reports DOWN when the connection is refused, times out, the hostname cannot be resolved, or the network cannot be reached.

The check is intentionally small: it does not log in, send a protocol command, or validate application data. It answers one question: can this service accept a TCP connection from Simple Ping right now?

Choose the port users actually depend on

Monitor the public service endpoint, not an internal address that Simple Ping cannot reach. Common examples include:

• 443 for HTTPS
• 22 for public SSH administration
• 25 or 587 for mail transport or submission
• 993 for IMAP over TLS
• a documented application port for a service you operate

Only monitor systems and ports you have permission to test. A service behind a private VPN cannot be reached by the public Simple Ping server unless a suitable public endpoint is intentionally exposed.

Set up a TCP checker

1. Choose Port in the checker type selector.
2. Enter a public hostname or IP address and a single port from 1 to 65535.
3. Add a display name that identifies the service, such as Primary mail - SMTP.
4. Run Check state now to test the connection from Simple Ping.
5. For services that restart during maintenance, use two consecutive downs to avoid alerting on one missed minute.

Know what the result does not prove

An open port does not prove that the application behind it is healthy. Port 443 may accept TCP while the website returns HTTP 500. A mail server may accept a connection while delivery is delayed. Pair a TCP checker with a webpage checker or a more specialized application test when the content matters.

A DOWN history row records the TCP exit code and a readable connection reason. Because the probe sends no application data, there is no page or protocol response body to display.