When setting up uptime monitoring for production infrastructure, most developers reach for standard HTTP/HTTPS uptime checkers. For web applications, SaaS dashboards, and public REST APIs, sending an HTTP GET request to / or /health works well.
However, modern backend infrastructure consists of many critical services that do not run web servers:
- PostgreSQL, MySQL, and Redis database nodes
- Bare-metal Linux VPS servers and SSH bastion hosts
- WireGuard and OpenVPN site-to-site network tunnels
- Game servers (CS2, Minecraft) and real-time VoIP gateways
When you enter a raw IP address (such as 103.205.128.10) or database host into a traditional HTTP uptime monitor, it automatically attempts to connect to port 80 or 443. Because no web server is listening, the check fails with ECONNREFUSED or Connection timed out—reporting your server as DOWN, even though the host is powered on and healthy.
This guide explains how IP Address & Network Ping Monitoring works, the technical differences between ICMP Echo and TCP Socket probes, and how to monitor your non-HTTP infrastructure with instant emergency alerts.
1. Why HTTP Monitors Fail on Non-Web Infrastructure
An HTTP uptime monitor relies on the entire Application Layer (Layer 7 of the OSI model):
Layer 7 (Application) : HTTP / HTTPS (GET /health -> Expects HTTP 200 OK)
Layer 4 (Transport) : TCP Handshake (SYN -> SYN-ACK -> ACK on Port 80/443)
Layer 3 (Network) : IP Packet Routing & ICMP Echo Reachability
If your server is a Redis instance listening strictly on port 6379, or a private database on port 5432, any HTTP probe to port 80/443 will fail during the TCP handshake. The operating system kernel immediately returns a TCP RST (Reset) packet, resulting in a false alarm:
[ HTTP Probe ] ──( SYN to Port 80 )──> [ Target: 103.205.128.10 ]
[ HTTP Probe ] <──( RST / Connection Refused )── [ Kernel ]
--> False Alarm: Monitor marks server as DOWN!
To monitor these servers accurately, you must test reachability at the Network Layer (ICMP) or Transport Layer (TCP).
2. ICMP Ping vs. TCP Ping: What is the Difference?
1. ICMP Ping (Internet Control Message Protocol)
ICMP operates directly at Layer 3. When you run ping 103.205.128.10, your computer sends an ICMP Echo Request (Type 8) packet. If the destination server is online and its firewall permits ICMP, it returns an ICMP Echo Reply (Type 0) packet.
- Advantage: Requires no listening ports or running software. It verifies whether the operating system kernel and network interface card (NIC) are online.
- Limitation: Many cloud providers (AWS security groups, Cloudflare) and enterprise edge firewalls block inbound ICMP traffic by default to prevent ping floods.
2. TCP Socket Probes
A TCP ping tests reachability by initiating a TCP three-way handshake (SYN) to a specific target port (such as :22 for SSH, :5432 for Postgres, :3306 for MySQL, or :80 for web).
- Advantage: Penetrates firewalls where ICMP is blocked, while validating that specific application daemons are actively accepting connections.
- Proof-of-Life Detection: If a port is closed, an immediate TCP
RSTresponse from the host still proves the machine is online and powered on.
3. How Pingzo's Dual-Layer Ping Engine Works
To eliminate false positives, Pingzo employs an intelligent dual-probe architecture:
[ Target Server: 103.205.128.10 ]
│
┌──────────────────────────────┴──────────────────────────────┐
▼ ▼
[ Probe 1: ICMP Echo ] [ Probe 2: TCP Socket ]
Sends native ICMP echo packet. Tests socket connection / RST.
Extracts RTT latency in milliseconds. Confirms OS kernel network stack.
│ │
└──────────────────────────────┬──────────────────────────────┘
▼
[ Intelligent Evaluator ]
Alive (ICMP reply OR TCP proof of life)
│
▼
[ 3-Strike Verification ]
(Alerts only on 3 consecutive failures)
- ICMP Ping First: Pingzo attempts a low-latency native ICMP echo request, capturing precise round-trip time (RTT).
- TCP Socket Fallback: If ICMP is filtered by a firewall, Pingzo automatically tests reachability via non-blocking TCP socket verification.
- 3-Strike Confirmation: Internet routing can have momentary transit blips. Pingzo re-verifies failures across 3 cycles before triggering an alert, eliminating noisy false alarms.
4. Top Workloads to Monitor with Ping
| Infrastructure Type | Recommended Target | Verification Method |
|---|---|---|
| PostgreSQL / MySQL Databases | db.internal.net:5432 | TCP probe + Latency tracking |
| Bare-Metal Linux VPS | 103.205.128.10 | ICMP Ping + SSH port 22 fallback |
| Redis / Memcached Nodes | redis.prod:6379 | TCP reachability |
| VPN / WireGuard Gateways | vpn.company.com:51820 | ICMP Echo + RTT tracking |
| Game Servers (Minecraft/CS) | game.server.io:25565 | TCP / ICMP reachability |
5. Setting Up Free IP Monitoring in 30 Seconds
Pingzo includes native IP & Network Ping monitoring on the Free Tier:
- Sign Up for Free: Create an account at Pingzo (no credit card required).
- Add Monitor: Select IP / Ping from the monitor types.
- Configure Target:
- Enter your IPv4/IPv6 address (e.g.,
103.205.128.10) or hostname. - (Optional) Add a custom port (e.g.
103.205.128.10:5432).
- Enter your IPv4/IPv6 address (e.g.,
- Choose Check Frequency & Alerts:
- Free Plan (₹0 / $0): 1 monitor with 15-minute check intervals and Email alerts.
- Starter Plan (₹399/mo / $5/mo): 10 monitors with 5-minute check intervals and instant Official WhatsApp & Telegram alerts.
- Pro Plan (₹999/mo / $12/mo): Unlimited monitors with 2-minute check intervals and full multi-channel routing.
Summary
Don't let unmonitored database hosts or network gateways cause silent outages. By combining ICMP echo requests and TCP socket probes, you can track server reachability and latency without having to install heavy agents or run unnecessary web servers.
Start Monitoring Your IP for Free →
Stop Finding Out About Outages from Angry Users
Get instant WhatsApp & Discord alerts the second your API, website, or server goes down. Setup in 30 seconds with 60-second checks.