What ports can I monitor?

Any TCP port from 1 to 65535. Common cases: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), database listeners (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), custom application ports.

Does the monitor check if the service is healthy or just reachable?

Just reachable — the monitor opens a TCP connection and checks whether the daemon accepts it. No protocol-level handshake. If you need protocol-aware checks (e.g. SMTP banner verification, database query response), use HTTP check (for HTTP-based services) or a self-hosted heartbeat agent.

What's the timeout for port checks?

Default 10 seconds. Configurable per monitor. If the TCP connection doesn't establish within the timeout window, the check fails with "connection timeout". Long-haul connections (e.g. checking a server in Asia from Europe) may need longer timeouts.

Can I monitor UDP ports?

Not currently. UDP is connectionless — there's no equivalent of "connection accepted" to check. UDP-based services typically require protocol-specific probes (e.g. DNS query for port 53, SNMP get for 161). Use heartbeat monitoring instead.

Does port monitoring count against TLS/SSL warnings?

No — port checks are pure TCP reachability. If you want TLS certificate validation on the port, use HTTPS check with the port in the URL (e.g. https://api.example.com:8443/) which does both reachability AND certificate inspection.

TCP Port Monitoring — Databases, Mail, Services

Confirm critical services are listening - not just your web server. Watch any TCP port on any host.

Beyond HTTP: monitoring the rest of your stack

Most services that keep a business running aren't web servers. Databases listen on 5432 (Postgres), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis). Mail flows through 25, 465, 587, 993, 995. SSH on 22. Game servers on whatever port the publisher picked. Internal microservices behind your firewall on whatever the platform team configured. None of these speak HTTP. None of them show up in a website uptime tool. And every one of them, when it stops listening, takes something visible down with it.

Port monitoring closes that gap. You give the monitor a host and a port, and on every check it opens a TCP connection and verifies the service is listening. If the connection fails - because the daemon crashed, the firewall changed, the host is down, or the network between us and the service is broken - you get an alert.

What you can monitor

Database servers: 5432 (Postgres), 3306 (MySQL/MariaDB), 1433 (SQL Server), 27017 (MongoDB), 6379 (Redis), 9042 (Cassandra), 11211 (Memcached).
Mail servers: 25 (SMTP), 465 (SMTPS), 587 (submission), 110 (POP3), 143 (IMAP), 993 (IMAPS), 995 (POP3S).
Remote access: 22 (SSH), 3389 (RDP), 5900 (VNC).
File transfer and storage: 21 (FTP), 990 (FTPS), 445 (SMB), 2049 (NFS).
Custom or internal services: GraphQL gateways, gRPC servers, message queues (RabbitMQ on 5672, Kafka on 9092), search engines (Elasticsearch on 9200, Solr on 8983), game servers, IoT devices.

How the check works

The monitor opens a raw TCP connection to host:port with a 5-second timeout. If the SYN/ACK comes back, the port is reachable and a service is listening - check is up. If the connection is refused, times out or fails to route, the check is down and the kernel-level error is recorded ("connection refused", "operation timed out", "no route to host") so triage is faster.

The monitor doesn't try to speak the application protocol on the port - it doesn't issue an SQL query or send an SMTP HELO. That keeps the check fast and side-effect-free, which matters when you're checking 100 services every minute. If you need application-level verification, combine port monitoring with a heartbeat or a custom API monitor that exercises the actual service.

Combining with HTTP and ping

For each public service, three monitors give you a clean diagnostic ladder. Ping confirms the host is alive on the network. Port monitoring confirms the service is listening. HTTP / API monitoring confirms the service is actually responding correctly. When something fails, the failing layer tells you immediately where to look. If only HTTP fails, the application crashed. If port also fails, the daemon died. If ping also fails, the box is gone or the network is down.

Setup

Open the tool, click "Add monitor", pick type "TCP port", paste the host (no protocol), enter the port number (1-65535) and pick an interval. Save. From the next cycle onwards, the monitor opens a TCP connection on every check, records round-trip time, and alerts you the moment the port stops accepting connections - via Email, Telegram, Slack, Discord or SMS, with the same confirmation period and quiet-hours rules as your other monitors.

Frequently asked questions

What ports can I monitor?
Any TCP port from 1 to 65535. Common cases: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), database listeners (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), custom application ports.
Does the monitor check if the service is healthy or just reachable?
Just reachable — the monitor opens a TCP connection and checks whether the daemon accepts it. No protocol-level handshake. If you need protocol-aware checks (e.g. SMTP banner verification, database query response), use HTTP check (for HTTP-based services) or a self-hosted heartbeat agent.
What's the timeout for port checks?
Default 10 seconds. Configurable per monitor. If the TCP connection doesn't establish within the timeout window, the check fails with "connection timeout". Long-haul connections (e.g. checking a server in Asia from Europe) may need longer timeouts.
Can I monitor UDP ports?
Not currently. UDP is connectionless — there's no equivalent of "connection accepted" to check. UDP-based services typically require protocol-specific probes (e.g. DNS query for port 53, SNMP get for 161). Use heartbeat monitoring instead.
Does port monitoring count against TLS/SSL warnings?
No — port checks are pure TCP reachability. If you want TLS certificate validation on the port, use HTTPS check with the port in the URL (e.g. https://api.example.com:8443/) which does both reachability AND certificate inspection.

Port Monitoring