A ping is not monitoring
Every network problem I have ever chased started the same way: something feels
slow, someone runs ping, the ping succeeds, and the investigation dies with
a shrug (case closed, apparently). The link was fine for one packet, once, from one place. That is not
monitoring. That is a coin flip with a timestamp.
kPong is what came out of taking that annoyance seriously. This note is about the gap between a ping and an answer - and what a small tool has to do to close it.
What a single ping cannot see
A successful reply proves reachability at one instant. The problems that actually ruin an evening live everywhere else:
- Jitter (variation in latency between probes). A link sitting at 20 ms with spikes to 800 ms feels broken. A single manual check almost always lands between the spikes and reports the 20 ms.
- Brief outages. A connection dropping for three seconds every few minutes will pass almost every manual check and fail almost every video call. A monitor only catches what its probe interval (time between consecutive measurements) can see - which is exactly why the interval is a setting and not a constant.
- Patterns. Degradation that follows a schedule - the evening congestion, the backup window - is invisible without history.
- Scope. One target cannot tell you whether the problem is your Wi-Fi, your ISP, or the far end. Several targets failing - or not failing - together narrows it down considerably. Narrows, not proves.
What it takes instead
The ingredients are not exotic. Skipping them is how a useful probe turns into a toy with a timer.
A scheduler, not a loop. Each target is probed on its own interval, continuously, whether or not anyone is watching. kPong gives every target its own timer, refuses to let a target overlap its own previous probe, and caps concurrent probes globally. When the scheduler stops or config reloads, in-flight work is aborted and a generation counter (a run identifier that rejects older results) discards stale results - a probe from the previous run cannot pollute the current one. The point is being there when the problem happens, not when the human does.
A baseline you can trust. The reference point is the median (the middle value after sorting samples) of a rolling sample window, not the mean. Using the mean here is a lazy default that lets one 900 ms outlier drag the baseline visibly while the median barely moves. That is exactly the property you want from the number that defines "normal" - the tail still gets watched, just not by the baseline.
Compound conditions, not tripwires. One slow sample proves little; a pattern is an event. A spike in kPong has to clear three bars at once: an absolute margin over the baseline, a relative one, and a clear jump above the previous sample. And after it fires, the target enters a cooldown (delay before another alert can fire) and disarms until latency settles back near baseline - so one sustained incident produces one alert instead of one per probe. For this workload, a one-threshold alarm is a noise generator. It gets muted after an hour and deserves it.
Explicit states. A sample is not "fine" or "down" - it is ok,
timeout, dns_error, unreachable, or unknown, and the distinction
matters: a resolver problem and a dead route feel identical from the couch
and have completely different fixes. Making states first-class means the UI
can say "this link is degrading" while a bare ping would still report
success.
History that leaves the terminal. Live views are for watching; the local SQLite history and timestamped CSV/JSON snapshots are for proving. "The link degrades every evening at eight" is an argument you can now have with an ISP (they love this), with data attached.
A UI that respects the terminal. kPong runs where the problem is - over SSH, on whatever box is closest. Targets are managed from the keyboard while it runs, config and themes reload without a restart, and the display stays readable on the exact kind of bad link it exists to diagnose.
What it still is not
kPong observes latency and reachability from where it runs, and that boundary is stated, not hidden. Claiming more would be bullshit. It can show you that a link is degrading, when, and how badly. It cannot tell you why - it will not name the guilty cable, and it does not try to be a monitoring platform with servers and pager rotations. And it measures ICMP (network protocol used by ping for control and diagnostic messages), which routers may treat differently from your actual traffic: a clean ping graph is strong evidence, not a verdict.
It occupies the space between ping and a full observability stack: small
enough to start in a minute, persistent enough to catch the problem that only
happens when you are not looking.