The short answer
Use an HTTP or HTTPS monitor when the user-facing result matters: a web page, API route, login screen, checkout step, webhook receiver, or health endpoint. Use a TCP monitor when the basic network service matters: SSH, SMTP, database listener, message broker, VPN port, or a custom service that does not speak HTTP.
The mistake is choosing only one. A public SaaS app usually needs both. HTTP monitoring tells you whether customers can use the product. TCP monitoring tells you whether an underlying service is accepting network connections. One is not a replacement for the other.
What an HTTP monitor actually proves
An HTTP monitor opens a request to a URL and evaluates the response. At the simplest level it checks the status code: 200 is normally healthy, 301 and 302 are redirects, 404 means missing content, and 500 class responses point to server-side failure.
HTTP checks become much more useful when you add rules that reflect the page's job. A login page should return a 200 response and contain a stable word such as "Sign in." A JSON health endpoint should return a response body that includes "ok" only after the app has confirmed the database and required dependencies are reachable. A public status page should load quickly and show current incident state.
HTTP monitoring is the right default for websites and APIs because it follows the same route a browser, bot, customer, or integration uses.
What a TCP monitor actually proves
A TCP monitor opens a socket to a hostname and port. It proves that the network path is reachable and that something is listening on the port. It does not prove that the application is returning correct business content.
For infrastructure teams, that is still valuable. If a PostgreSQL listener stops accepting connections, an SSH port disappears, or a queue service is no longer reachable, TCP checks catch the failure before an HTTP app may expose it. TCP checks are also useful when an internal system does not have an HTTP health route.
Failure examples
| Failure | HTTP check result | TCP check result |
|---|---|---|
| Expired TLS certificate on a website | Fails or warns, depending on SSL validation | Often passes because port 443 is still open |
| Application returns a blank 200 page after deploy | Can fail if you use keyword validation | Passes because the web server accepts connections |
| Database port blocked by firewall | May fail only after the app hits that dependency | Fails directly on the database listener |
| Nginx is up but PHP-FPM is down | Fails with 502 or 503 | Passes on port 443 unless the proxy also stops |
A practical monitor set
For a normal web application, start with one HTTPS check for the homepage, one HTTPS check for the login or account page, one API health endpoint, and one TCP check for any externally reachable service that is critical to recovery. If you operate ecommerce, add checkout and payment-adjacent endpoints. If you operate a customer API, add the docs page and one lightweight authenticated or synthetic route if your tooling supports it.
Keep the labels operational. A monitor named "App" is vague during an incident. A monitor named "api.statusintel.com health endpoint" tells the responder where to look first.
How StatusIntel fits
StatusIntel supports HTTP, HTTPS, TCP, and ping-style checks so a small team can separate application health from network reachability. Use the free website status checker for one-off tests, then create persistent monitors in the dashboard for routes where downtime would create customer impact.