Most monitoring tools offer several check types and most teams use exactly one. Here is what each one actually tests.
ICMP ping
The lightest check. If the host answers, the machine is powered on and reachable at the IP layer. That is all it proves — a host can answer ping perfectly while every service on it is dead. Use it for network reachability of routers and appliances, and to distinguish "the machine is gone" from "the service is broken." Note that many cloud providers block ICMP by default.
TCP check
Opens a socket to a host and port. If the connection establishes, something is listening, which means the process is running and firewall rules permit the path. Use it for databases, brokers, caches, SSH. A passing check on port 5432 means Postgres is accepting connections; it does not mean it can authenticate you or that queries return. For most teams the port check is a reasonable proxy, but be clear that it is a proxy.
UDP check
Connectionless, so it is only meaningful if the service replies to something. Configure both the payload to send and the response to expect. Use it for DNS and specific application protocols.
HTTP and HTTPS check
The richest option, and the only type that can verify your application logic actually worked. Configure the status codes (empty means any 2xx counts), require a short distinctive body fragment rather than a full JSON snippet, and check headers if you need to. A POST check can exercise a real code path — just do not have your monitoring create a real order every minute.
The layered approach
For anything important, use a small ladder. For a Postgres-backed API: a ping check on the host, a TCP check on port 5432, and an HTTP check on your dependency-aware health endpoint. When the HTTP check fails but the other two pass, the problem is in your application. When the TCP check fails but ping passes, Postgres died but the host is fine. You have encoded the first three steps of your debugging in your monitoring, and it costs about ten minutes.