HTTP monitoring and TCP monitoring are often lumped together but they test fundamentally different things. Choosing the wrong one means blind spots — and blind spots mean outages you only discover when a user rings to complain.
What HTTP monitoring checks
An HTTP check sends a GET or HEAD request to a URL and evaluates the response. It can verify the status code (200 OK, 301 redirect, 404 not found), check for specific text in the response body, and measure response time. HTTP monitoring catches web server failures, application errors, broken reverse proxy configs, and CDN misconfigurations that return cached 200s with broken content.
What TCP monitoring checks
A TCP check attempts to open a connection to a specific host and port. It does not interpret any application protocol — it simply confirms the port is reachable. This makes it ideal for services that do not speak HTTP: SMTP (port 25/587), IMAP/POP3, FTP, MySQL/PostgreSQL, Redis, SSH, RDP, and custom application ports. A TCP check will tell you your database server port is closed long before your application starts throwing connection errors.
Where they overlap — and where they diverge
For a typical web service you want both. Your HTTP check confirms the application layer is healthy. Your TCP check on port 443 confirms the socket is open even if your application is returning 500 errors. The combination catches everything from a crashed Node process (HTTP fails, TCP may still pass) to a firewall rule change (TCP fails immediately, HTTP would also fail but for a different reason).
Common mistakes
Monitoring only HTTP for a mail server tells you nothing — SMTP runs on TCP 25/587. Monitoring only TCP for a web application misses application-layer errors that the web server swallows and returns as 200 with an error message in the HTML. The rule of thumb: monitor everything at the TCP layer, and add HTTP checks for every publicly-facing web service.
Running both on VP Watchtower
When you add a service to your VP Watchtower status page you choose the check type. You can add the same host twice — once as an HTTP check and once as a TCP check on a different port — to get both layers of coverage within a single status page.