TCP Health Checks

Overview

TCP health checks are a fundamental monitoring type that verifies whether a service is listening on a specific port and accepting connections. This is the ideal check type for databases, message brokers, cache servers, mail servers, and any other TCP-based service that does not use HTTP.

The check establishes a TCP connection to the specified host and port. If the connection succeeds, the service is considered healthy. Optionally, you can also verify a banner message that the service sends upon connection.

Configuration

How It Works

When a TCP health check runs, upti.my performs the following steps:

1. Resolves the hostname to an IP address (if a domain is provided)
2. Initiates a TCP connection to the resolved IP and specified port
3. If an expected banner prefix is configured, reads the initial data sent by the server
4. Compares the received banner against the expected prefix
5. Closes the connection and records the results

Banner Checking

Many TCP services send a banner or greeting message when a client connects. For example, an SMTP server might send 220 mail.example.com ESMTP, and a Redis server might respond with version information. Banner checking lets you verify not just that a port is open, but that the correct service is running behind it.

Response Data

Each TCP health check execution captures the following data:

Common Use Cases

• Databases - Monitor PostgreSQL (5432), MySQL (3306), MongoDB (27017), Redis (6379)
• Message Brokers - Check RabbitMQ (5672), Kafka (9092), NATS (4222)
• Mail Servers - Verify SMTP (25/587), IMAP (143/993), POP3 (110/995)
• Custom Services - Monitor any internal service listening on a TCP port
• SSH - Verify SSH servers are accessible on port 22

Example Configuration

{
  "host": "db.example.com",
  "port": 5432,
  "expected_banner_prefix": "",
  "timeout_seconds": 5,
  "interval_seconds": 60
}

{
  "host": "mail.example.com",
  "port": 25,
  "expected_banner_prefix": "220",
  "timeout_seconds": 10,
  "interval_seconds": 60
}