TCP port monitoring checks whether a port is open and accepting connections — without making any HTTP requests. This is how you monitor databases, message brokers, and any other services that don't speak HTTP.
How TCP monitoring works
UptimeWiz attempts to open a TCP connection to your specified host and port. If the handshake completes within 10 seconds, the check passes. If the connection is refused, times out, or drops, the check fails and the failure is sent for consensus re-verification before alerting.
Setting up a TCP monitor
- From the dashboard, click New Monitor
- Select TCP as the monitor type
- Enter the hostname or IP address of your server
- Enter the port number (e.g. 5432 for PostgreSQL)
- Set the check interval — 1 minute is recommended for production databases
- Add at least one alert channel
- Click Save
Common ports reference
- PostgreSQL: 5432
- MySQL / MariaDB: 3306
- MongoDB: 27017
- Redis: 6379
- Elasticsearch: 9200
- SQL Server: 1433
- Cassandra: 9042
- ClickHouse: 9000
- SMTP: 25 / 587
- SSH: 22
What TCP monitoring catches
- Database process crash — the port stops accepting connections
- Out-of-disk conditions that prevent new connections
- 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 queries, returns errors, or has run out of memory for query execution will still pass a port check.
For full coverage, pair TCP monitoring with an HTTP monitor pointing to a /health endpoint in your application that internally runs a lightweight test query (e.g. SELECT 1).
Security note
Most production databases should not be exposed to the public internet. If your database is inside a private network or VPC, external TCP monitoring will fail by design — and that's correct. Use an application-level /health endpoint as a proxy instead.
Combine TCP monitoring with an HTTP /health endpoint that tests database connectivity. TCP tells you the port is open; HTTP tells you queries actually work.