Ping (ICMP) monitoring for servers, routers and anything with an IP

One packet, three seconds

A ping check is deliberately small. Tenium resolves the host, refuses private addresses, and sends a single ICMP echo request, waiting up to three seconds for the reply. A reply counts as up and its round-trip time in milliseconds becomes the response time; no reply is a failure. There is no packet-loss percentage and no jitter figure, because there is only one packet per check. What you do get is history: a flaky line shows up as a pattern of isolated failures and slow replies across hundreds of checks, and the confirmation step stops one lost packet from becoming an incident.

When a failure happens, other regions re-send the probe. With 2 regions live, a router that is truly down fails from all of them, while a transit problem on one route fails from only one and is not escalated.

When your firewall eats the echo

The most common reason for a ping monitor that is always red is a target that does not answer ICMP at all. Default cloud security groups, some hosting providers, and hardened firewalls drop echo requests silently, so the machine is fine and the monitor is not. Allow ICMP echo from the addresses on the checker IP list, or switch to a TCP port monitor on a port you know is open.

Tenium does have a fallback, but it is narrower than it sounds. If the checker machine itself is not allowed to send ICMP, the check connects to TCP 443 and then 80 instead and records that it did so. If your target is the one dropping ICMP, there is no fallback and the check fails.

What an answered ping does not prove

ICMP is answered by the operating system's network stack, not by your application. A web server can crash, a database can hang and a disk can fill while the kernel keeps replying to pings perfectly. For anything with an HTTP interface, an HTTP monitor is the honest check, and ping is the supporting evidence.

Used together, the two narrow the cause fast:

• Ping up, HTTP down: the host and the network are fine; look at the web server, the application or a deploy.
• Ping down, HTTP down: the host, the network or the upstream provider; start with the provider's status page.
• Ping up from some regions and down from others: a routing or peering fault, usually not yours to fix.
• Ping slow and HTTP slow: a saturated link or an overloaded host rather than a code regression.

What ping is really good for

It earns its place on infrastructure that has an address but no web interface: a VPN gateway, a branch office router with a static IP, a firewall appliance, a NAS, a managed switch that is reachable from outside, or a colocated server that you want to watch independently of the software on it. It is also the cheapest first monitor for a new server before any service is installed. Ping is available on every plan, with 5 min checks on Free and as fast as 30 s on Pro and Agency.

Remember the limits of the vantage point: the checkers sit on the public internet, so internal addresses (10.x, 192.168.x, 172.16-31.x) are rejected. To watch something inside a private network, expose a safe endpoint from it and monitor that, or ping out of the network with a cron heartbeat.

Reading latency charts

Round-trip time is dominated by distance, so compare each region against its own baseline instead of against the others. A London checker reaching a Frankfurt server in 15 ms and a New York checker in 90 ms is normal. A sudden doubling of one region's line, with the others flat, points to a route change. Pro and Agency can set a slow threshold, which raises a degraded incident when the recent average climbs over it; see response-time alerts.