Ping is not uptime monitoring: what ICMP proves, what a TCP connect proves, and why a failure needs a second witness

What ping actually proves

ping sends an ICMP echo request and waits for the echo reply. The reply comes from the network stack of the machine that owns the address, not from any program running on it: on every common operating system the kernel answers echo requests by itself, before any service is involved. So a reply proves four things and no more: the address is assigned to something, there is a route to it and back, and the machine's network stack is running.

That is a useful list for someone tracing a path. It is not what your users mean by "up": the web server answering, the API returning their data, the VPN accepting a tunnel. None of that happens in the kernel, and none of it is visible to ICMP.

Why a host that answers ping can be down

Everything that turns a running machine into a working service sits above the layer ping can see. Each of these takes the service down while the machine keeps replying.

The process is not running. It crashed, the kernel killed it for memory, or it never started after a reboot. The port is closed; ping is fine.

The port is filtered. A firewall rule was tightened, a security group changed, an ISP started blocking a port. The packet is dropped while ICMP is still let through.

The process is running but wrong. The web server returns 502 from a backend that is gone, the disk is full so every write fails. The machine has never been healthier.

The address is not the service. A load balancer or a CDN edge answers ping as long as it exists, whatever happened to the servers behind it.

The opposite failure is as common. Many hosts and cloud firewalls drop ICMP by default, and routers on the path rate-limit it, so a ping monitor reports a host dead while every customer is being served, and after a few false alarms nobody reads its alerts.

A TCP connect on the port that matters

A TCP connection is a three-step handshake: your side sends a SYN, the host answers SYN-ACK, your side confirms with ACK. For the SYN-ACK to come back, a program must be bound to that port and the kernel must have accepted the connection on its behalf. That is the difference. Ping proves a machine; a connection to port 443 proves that something on the machine is listening where HTTPS lives.

The failures are distinct too. An immediate refusal (a RST packet) means the host is there and nothing listens on the port. A timeout means the packet was dropped: a filter, a firewall, or a dead host. Each points at a different fix.

So the first step up from ping is a TCP monitor on the port the service uses: 443 for a website, 22 for SSH, 25 or 587 for mail, 5432 for PostgreSQL. hostnag's TCP monitor takes a host and a port and, on each run, records the address and port it connected to and how long the handshake took. hostnag never sends ICMP: it watches from the cloud with nothing installed on your side, so "ping" on its feature page means TCP reachability on a port you name. Private and loopback addresses are refused for the same reason: nothing in the cloud can reach them.

When a connection is not enough, ask for an answer

A port that accepts connections while the application behind it returns errors is the ordinary half-outage: the port is open, the page is a 500. For anything that speaks HTTP, ask for a real answer and judge it. hostnag's HTTP monitor makes the request and checks the status code against a range (2xx by default), looks for a keyword that must be present or absent (case-insensitive unless you say otherwise) or a regex, evaluates up to 10 JSON assertions on the body, can POST a body with custom headers, and can follow redirects or fail on any redirect. A page that returns 200 with "Service temporarily unavailable" in the body is down to your users and to a keyword rule; it is up to a status-code check and to ping.

Confirmed from a second place before anyone is paged

A single failed run from a single place is not an outage. The runner's own network can hiccup, a resolver can time out, one route can flap for a minute. Paging on that trains people to ignore pages.

hostnag runs availability monitors from up to 4 locations (US East, US West, Frankfurt, Tokyo): 1 on the Free plan, up to 3 on Pro and up to 4 on Business, and combines the verdict across them. A failing majority of at least two locations is down at once: two places that cannot reach a host are two independent witnesses. A lone failure is not enough. From one of several locations it leaves the monitor where it was; from the only location, the monitor is confirmed down when it fails 2 runs in a row. Inside a run, a transient error (a connection that never completed, a resolver that did not answer) is retried before anything is written down, and a run in which the runner itself was unreachable is no evidence about your host at all.

The alert says where: down from how many of the locations, which ones, since when, and the last error (unexpected_status: 503, connect_failed, a timeout). When the host answers again from every location, a recovery notice says how long it was down.

How often to check, and what that means for time to page

Check intervals are presets: 1, 5, 15, 60, 360, 1440 minutes. The Free plan checks every 5 minutes from one location; Pro and Business go to every 1 minute. Each run waits up to 10 seconds for an answer by default and 15 at most.

Put the two rules together for the worst case. A one-location monitor on a 5-minute interval needs 2 failed runs, so an outage that begins just after a run is confirmed about 10 minutes later. A monitor watched every 1 minute from two or more locations is confirmed on the first run that fails from a majority of them.

Slow is its own state

Down is binary; slow is what users complain about first. Two settings cover it.

A latency threshold, in milliseconds, per monitor. When every location connects but the median latency across them is above the threshold, the monitor is Degraded rather than Up: a warning, not an outage, and the alert names the median it measured. Degraded alerts are a switch on the group's alert policy, off until you turn it on, so a threshold set only to colour the board never pages anyone.

A daily p95 SLO, on HTTP monitors. Set a target in milliseconds and hostnag computes the 95th percentile of latency over the last day of confirmed runs, once there are enough of them for a percentile to mean anything, and raises one degraded alert per day while it is above the target, naming the p95, the target and the number of runs. In the alert's own words, "It is not down, only slower than you promised." Setting the target is the opt-in; the degraded switch does not gate it. A percentile, because an average hides a slow tail behind many fast requests.

Check one by hand

ping -c 3 example.com
nc -vz example.com 443
curl -sS -o /dev/null -w '%{http_code} connect=%{time_connect}s total=%{time_total}s\n' https://example.com/

The first says that the machine's stack answers, or that ICMP is filtered on the way, and nothing more. The second attempts the handshake and reports whether something listens on 443, with "Connection refused" and a timeout as the two kinds of no. The third asks for a real answer and prints the status code, the time to connect and the total time a visitor waits.

Check it now, then watch it

Check it now: put a host and port into the port checker to see whether a connection reaches it from the internet, or a URL into the HTTP checker for its status code, final address and latency. Both run once from the runner a monitor uses.

Watch it for good: uptime monitoring makes the connection or the request on its schedule from up to 4 locations, confirms a failure before anyone is paged and tells you when the host is back. For an office or ISP connection, link monitoring makes the same TCP connect to the gateway's public address and adds an optional inside half, a heartbeat a device behind it calls, so a filtered port and a dead line stop looking alike; see monitoring an office internet link.