ICMP vs TCP Monitoring: Which Should You Use?

ICMP monitoring (ping) sends an echo request to a host's IP address and waits for a reply. It operates at the network layer (Layer 3) and answers one question: is this host reachable on the network? It doesn't know or care what services are running. A host can reply to ping while every application on it is crashed.

TCP monitoring (port check) attempts to open a TCP connection to a specific host and port. It operates at the transport layer (Layer 4) and answers: is there a process listening on this port and accepting connections? It tells you a service is reachable but not whether it's functioning correctly — a database can accept TCP connections while refusing queries.

Use ICMP when you care about the host itself, not a specific service: network devices (routers, switches, firewalls), IoT hardware, bare-metal servers where you want a host-level heartbeat, or any situation where you need to know "is this machine on the network." It's also useful as a triage signal — if ping fails, the whole host is down; if ping succeeds but a port check fails, the host is up but the service isn't.

Be aware that some networks block ICMP for security reasons, and cloud providers occasionally rate-limit it. If ping is blocked on your target, you'll get false positives — switch to a TCP check on a known-open port instead.

Use TCP when you care about a specific service: databases (5432, 3306, 27017), mail servers (25, 587, 993), SSH (22), Redis (6379), message queues, or any non-HTTP service. TCP checks confirm the daemon is running and listening, which is usually what you actually want to know for infrastructure services.

For HTTP services, prefer HTTP monitoring over a raw TCP check on port 443 — the HTTP check gives you status codes and response time, which a port check can't. SurePing supports both ICMP (ping) and TCP (port) monitors on every plan, including Free, so you can layer them: ping for host reachability, port for service availability, HTTP for application health.