Monitoring an ISP link: what to measure beyond ping

Ping is the oldest network check and the least informative one. It answers a single question — is there an IP path — and stays silent about everything that actually breaks a customer's day.

Four checks that catch different failures

ICMP ping proves a path exists and gives a rough round-trip time. Useful for a circuit baseline. It does not prove the service behind the link works, and many networks deprioritise or block ICMP entirely, which turns a healthy link into a permanent red light.

TCP port check proves something is listening. A BGP session is up, a RADIUS server answers on 1812, a mail server accepts on 587. If the port is closed you know immediately whether it is the link or the service.

HTTP check proves the application answers with the status you expect. This is where most "the internet is down" complaints actually live: the link is fine, the customer portal returns 502.

TLS check proves the certificate serving that link is valid and not about to expire. For an ISP this is the difference between a routine renewal and a weekend of every customer seeing a browser warning.

Run all four against different parts of the network and you can tell, in one glance, whether a fault is local, upstream, or in the service itself.

Measure a baseline before you need it

Latency numbers are only meaningful against a baseline for your network. A 40 ms round trip to a Nairobi peer is excellent; the same figure to a local gateway is alarming.

Record, for each link you care about:

• median latency at a quiet hour
• median latency at peak
• packet loss percentage
• the time of day it usually degrades

Two weeks of data turns "it feels slow" into "it degrades 18:00–21:00, from 32 ms to 210 ms, every weekday". That is a report you can act on with an upstream provider.

Alert on change, not on every measurement

The fastest way to make an alert channel useless is to page on every failed probe. A single dropped packet is normal on any network. A link that flips between up and down ten times an hour is a real problem that deserves one notification, not ten.

Two mechanisms make this workable:

• Retries before alerting. Declare a link down only after two or three consecutive failures. This removes the noise from transient loss without hiding a real outage for long.
• State-change alerting. Notify when the state changes — down once, and recovered once. Never while it stays down.

If a channel is noisy, people mute it, and then they miss the one alert that mattered.

Reporting for customers and management

When a business customer asks why their link "keeps dropping", a screenshot of an availability strip is worth more than an argument. A month of history with incident timestamps, durations and recovery points shows whether the fault is on your side or theirs — and it is the artefact that resolves the billing conversation.

For that you need stored history, not just live status. A monitor that shows up and down but keeps no record cannot answer the only question anyone asks afterwards.

A practical starting set

• core gateway: ping every 60 s, TCP 443 every 60 s
• each customer-facing portal: HTTP every 60 s with a keyword assertion
• RADIUS, mail and DNS: TCP checks every 2 minutes
• every public TLS endpoint: certificate check every 6 hours
• upstream provider hand-off: ping plus HTTP through the link

Five to ten checks per important link catches the failures that generate support calls, at a cost far below one hour of an engineer's time.

Next: TLS certificate expiry.