Your website is the visible tip of an infrastructure iceberg. Beneath it: mail servers, databases, authentication services, internal APIs, backup agents, and custom application servers — none of which respond to HTTP checks. TCP port monitoring gives you visibility into all of them.
Common ports to monitor
SMTP (port 25, 465, 587) for email delivery. IMAP (993) and POP3 (995) for email retrieval. FTP (21) and SFTP (22) for file transfers. MySQL (3306), PostgreSQL (5432), and Redis (6379) for databases. RDP (3389) for remote desktop. Custom application ports vary by service. Add each one that represents a dependency your business relies on.
What TCP monitoring catches that HTTP misses
A web application with a broken database connection will typically still respond to HTTP checks with a 200 OK status — showing a cached page or an error page that returns 200 by mistake. A TCP check on port 3306 would show the database is unreachable. Mail delivery failures are invisible to HTTP monitoring entirely. FTP server failures, SSH connectivity, and custom API ports are all in the same category — critical but invisible to web-layer monitoring.
False positives and port accessibility
Some ports are intentionally closed to external networks — particularly databases, which should never be accessible from the public internet. TCP checks from external monitoring services will fail on these ports by design. Only add TCP checks for ports that are supposed to be externally accessible. For internal services, monitoring must run from within your network perimeter.
Firewalls and IP allow-lists
If your firewall blocks inbound connections by default and you want to monitor from an external service, you need to allow the monitoring service's IP addresses. Check the documentation for your monitoring tool to find the outbound IP ranges to allow. For VP Watchtower, checks are run from Vercel's edge network — if your service is behind a strict firewall, TCP checks may not be reliable from an external monitor.