50% bonus credits + 2x signup credits View Offer
Navigation

How do TCP monitors work?

Monitor TCP services like databases, mail servers, and custom protocols with connection and response checks.

TCP monitors test whether a TCP port is open and accepting connections. Unlike HTTP monitors, they work at the transport layer - making them the right tool for databases, mail servers, game servers, and any service that doesn’t speak HTTP.

How TCP Checks Work

When a TCP check runs, UpCanary:

  1. Attempts to open a TCP connection to the specified host and port
  2. If the connection succeeds and no Send Data is configured, the check passes
  3. If Send Data is configured, UpCanary sends the data and waits for a response
  4. If an Expected Response is configured, the response must contain that string for the check to pass

A check fails if the connection is refused, times out, or the response doesn’t match expectations.

Configuration Options

Host

The hostname or IP address to connect to.

db.yourapp.com
192.168.1.100
redis.internal

Both public hostnames and private/internal addresses are supported (for internal services, ensure they’re reachable from UpCanary’s monitoring regions, or use a region close to your infrastructure).

Port

The TCP port number to connect to. Must be between 1 and 65535.

Send Data (Optional)

Text to send over the connection after it’s established. Useful for protocols that require an initial command or handshake string.

PING\r\n
GET / HTTP/1.0\r\n\r\n

Leave blank if you only need to verify the port is open.

Expected Response (Optional)

A string that must appear in the response data for the check to pass. If the server responds but the response doesn’t contain this string, the monitor marks as Down.

+PONG
220

Leave blank to pass on any successful connection.

Timeout

Maximum time in milliseconds to wait for a connection and response. Defaults to 30000 (30 seconds).

Common Use Cases

Database Servers

TCP monitors are ideal for checking database port availability:

DatabaseDefault Port
PostgreSQL5432
MySQL / MariaDB3306
MongoDB27017
Redis6379
Elasticsearch9200
Microsoft SQL Server1433

Example - PostgreSQL:

Host: db.yourapp.com
Port: 5432
Interval: 1 minute

Example - Redis with response check:

Host: redis.yourapp.com
Port: 6379
Send Data: PING\r\n
Expected Response: +PONG
Interval: 1 minute

Mail Servers

Host: mail.yourcompany.com
Port: 25        (SMTP)
Expected Response: 220
Interval: 5 minutes

Other mail ports: 587 (SMTP submission), 993 (IMAP over SSL), 995 (POP3 over SSL).

Game Servers

Host: game.yourserver.com
Port: 25565     (Minecraft)
Interval: 5 minutes

SSH

Host: server.yourcompany.com
Port: 22
Expected Response: SSH-
Interval: 10 minutes

TCP vs HTTP Monitors

Use TCP when:

  • The service doesn’t speak HTTP (databases, mail, game servers)
  • You want the lightest possible check with minimal overhead
  • You need to monitor a non-standard protocol

Use HTTP when:

  • The service has an HTTP or HTTPS endpoint
  • You need to assert on status codes or response content
  • You want SSL certificate monitoring included