TCP Port Monitoring

Monitors TCP port availability and response time. Use this for non-HTTP services like databases, mail servers, message brokers, or any custom application that listens on a TCP port.

How It Works

Hoppla opens a TCP connection to the specified host and port. If the connection is established within the timeout period, the port is considered reachable. The response time measures how long the TCP handshake takes to complete.

By default, TCP monitoring does not send any application-layer data — it only verifies that the port is open and accepting connections. Optionally, you can send a probe string after connecting and assert on the response (see send_string / expected_response below).

Configuration

Setting	Description	Default
Host	Hostname or IP address to connect to	Monitor URL host
Port	TCP port number (1-65535)	Monitor URL port, or 80 if none
Timeout	Maximum time to wait for connection (seconds)	10
Send string	Optional probe string sent after connecting (max 1000 chars; CR/LF are stripped)	(none)
Expected response	Optional substring matched case-insensitively against the response/banner — a mismatch fails the check	(none)
Check interval	How often to check the port	60 seconds

If you omit the port, Hoppla uses the port from the monitor URL, or falls back to 80. The timeout is clamped to a maximum of 30 seconds at execution time, even though larger values are accepted at configuration.

Results

Field	Description
Status	Whether the connection succeeded or failed
Response time	TCP handshake duration (ms)
Welcome message	The banner the service returned on connect, if any (sanitized and truncated)
Error	Connection error details if the check failed (timeout, refused, unreachable, or expected response not found)

Example Result -- Success

TCP check: mail.example.com:587
  Status:        Connected
  Response time: 12ms

Example Result -- Failure

TCP check: mail.example.com:587
  Status:        Failed
  Error:         Connection refused
  Response time: --

Alerts

Event	Trigger	Severity
incident.created	TCP connection fails (refused, timeout, or unreachable)	Incident

An incident is opened when the port becomes unreachable and resolved automatically when connectivity is restored. Like uptime checks, TCP checks use dual-check verification -- a single failure is re-verified from a second location before triggering an alert.

Common Use Cases

Service	Default Port	Notes
SMTP (submission)	587	Outgoing mail server
IMAP	993 (TLS)	Incoming mail server
POP3	995 (TLS)	Incoming mail server
RabbitMQ	5672	Message broker
Elasticsearch	9200	Search engine
HTTPS	443	Web server socket
Custom application	Any	Your own services

Blocked ports

To prevent the platform from being used for port scanning, the following ports are blocked and cannot be configured for a TCP check: 22 (SSH), 23 (Telnet), 25 (SMTP), 110 (POP3 plaintext), 143 (IMAP plaintext), 3306 (MySQL), 5432 (PostgreSQL), 6379 (Redis), 11211 (Memcached), 27017 (MongoDB). To monitor a database or cache, monitor a port your application exposes instead, or use an HTTP uptime or application health check against a service that fronts it.

When to Use TCP vs. Uptime

• Use TCP monitoring when the service does not speak HTTP (databases, mail servers, SSH, custom protocols)
• Use uptime monitoring when the service has an HTTP/HTTPS endpoint you want to validate
• Use both when you want to monitor the network-level port and the HTTP application separately

Security Note

TCP monitoring verifies that a port accepts connections and, optionally, sends a probe string and asserts on the response. It does not authenticate or send credentials. To prevent abuse for port scanning, a set of sensitive service ports (SSH, Telnet, SMTP, plaintext POP3/IMAP, and common database/cache ports — see Blocked ports) cannot be monitored.