TCP Monitor

Monitors TCP connections to specific ports on a server. Used for uptime monitoring of non-HTTP services such as databases and mail servers.

Use a TCP monitor when you need to confirm that a specific port is reachable from the public internet, such as a database, mail, or SSH port. A successful connection is considered healthy; the monitor does not issue protocol-specific commands, authenticate, or validate response content.

• Check whether a non-HTTP service is listening
• Verify public firewall and port reachability
• Monitor connection success without evaluating an HTTP response code

Use an HTTP monitor when application response content matters, or a Ping monitor when you want a simple host-level check with an optional port.

1. Open “New Monitor” from the service detail page and select TCP.
2. Enter a publicly resolvable hostname without a scheme or path.
3. Enter the port on which the service actually listens. Common examples include SSH 22, SMTP 25 / 587, PostgreSQL 5432, MySQL 3306, and Redis 6379.
4. Choose a timeout that allows for normal connection delay. A value that is too short turns transient latency into failures; one that is too long delays detection.
5. Select an interval allowed by your plan and create the monitor.

See the Monitor Screens reference for the fields, accepted ranges, and defaults shown in the dashboard.

• Ports 443 and 8443 are probed with an HTTPS HEAD request. Any HTTP response, including 4xx or 5xx, means the port is up.
• All other ports use a raw TCP connection and are up when the connection opens.
• Connection refusal, DNS failure, or failure to connect within the timeout produces down.
• Application-protocol content and authentication results are not checked.

See Monitoring Lifecycle for when a down result becomes an incident.

Symptom	What to check
Connection timed out	Verify the port, public firewall, and listening process; raise the timeout if normal connections need longer
The connection is refused	Confirm that a process listens on the selected port and that DNS points to the intended server
A non-HTTP service on 443 / 8443 fails	These two ports use HTTPS HEAD. Consider exposing the service on a different port for a raw TCP probe
A 4xx / 5xx response is still up	TCP monitoring checks reachability. Switch to an HTTP monitor to evaluate HTTP status
The port is up but service operations fail	Authentication and protocol commands are not checked. Add a protocol-aware health endpoint or another monitor
The hostname cannot be saved	Use a public hostname rather than localhost, a private IP, or an internal host