Port monitoring for databases explained

Most uptime monitors work by making HTTP requests and checking for a response code. This works perfectly for websites and APIs, but databases are different — they don't speak HTTP. TCP port monitoring solves this by making a raw connection check instead.

What TCP port monitoring actually checks

A TCP port check attempts to open a connection to a specific host and port. If the connection succeeds (the TCP handshake completes), the port is considered reachable. If it times out, is refused, or drops the connection, the check fails.

This is a network-layer check. It tells you that the database process is running, listening on its configured port, and reachable from the monitoring probe — but it does not execute queries or test the database's internal health.

Common database ports to monitor

• PostgreSQL: port 5432
• MySQL / MariaDB: port 3306
• MongoDB: port 27017
• Redis: port 6379
• Elasticsearch: port 9200
• SQL Server: port 1433
• Cassandra: port 9042
• ClickHouse: port 9000

What TCP monitoring catches

• Database process crash — the port stops accepting connections
• Out-of-disk conditions that prevent new connections from being accepted
• Network firewall rule changes that block access
• Container or pod restarts that cause a gap in availability
• Connection limit exhaustion — new connections are refused

What TCP monitoring doesn't catch

TCP monitoring confirms connectivity, not correctness. A database that accepts connections but hangs on every query, returns corrupt data, or has run out of memory for query execution will still pass a port check.

The best practice is to combine TCP monitoring with an HTTP health endpoint in your application. A simple /health route that executes a lightweight test query (e.g. SELECT 1 on PostgreSQL) catches both connection-level and query-level failures, while the TCP check independently verifies that the port is reachable at all.

Setting up TCP monitoring in UptimeWiz

1. Click New Monitor in the dashboard
2. Select TCP as the monitor type
3. Enter the hostname or IP address of your database server
4. Enter the port number
5. Set the check interval (1 minute recommended for production databases)
6. Add an alert channel
7. Save

Security considerations

Most production databases should not be exposed to the public internet — they should only be reachable from within your private network or VPC. External TCP monitoring will always fail by design for these, which is correct.

For internal databases, TCP monitoring is most useful when combined with an application-level /health endpoint that is publicly reachable and internally tests the database connection. The HTTP monitor gives you external visibility; the TCP monitor gives you a direct network-layer signal.