Monitor type comparison
| Type | Best for | What it proves |
|---|---|---|
| HTTPS | Public websites, dashboards, APIs, status pages | The route is reachable over TLS and returns an acceptable web response. |
| HTTP | Internal apps, redirect tests, non-TLS legacy routes | The route is reachable without TLS. Use only when HTTPS is not appropriate. |
| TCP | SSH, SMTP, databases, queues, custom ports | A socket can be opened to the target host and port. |
| Ping | Basic host reachability | The host responds to ICMP where network policy allows it. |
Use HTTPS for user-facing pages
HTTPS checks are the default choice for public web properties. They catch DNS, TLS, routing, reverse proxy, and application-level errors that a simple port check may miss. They also reflect how browsers, crawlers, and customers reach the site.
Use TCP for service reachability
TCP checks are useful when you need to know whether a network service is accepting connections. A passing TCP check does not prove business logic is healthy, but it is valuable for diagnosing whether the failure is at the network, port, or application layer.
Use ping carefully
Ping is a coarse signal. Some healthy hosts block ICMP, and some unhealthy services still live on a host that responds to ping. Treat ping as a basic reachability check, not a replacement for HTTP or TCP monitoring.
Combine checks for stronger incident diagnosis
If the HTTPS monitor fails but the TCP monitor on port 443 passes, the web server may be reachable while the app stack is broken. If both fail, look at DNS, firewall, proxy, host, or provider networking first. Splitting those signals saves time during response.