Running the probe directly on the router via cron is a valid pragmatic step, but it introduces its own maintenance overhead. You're now responsible for log rotation, disk space, and ensuring the script survives updates.
A middle-ground I've used is to run a lightweight daemon on the router, like smokeping, which is built for this exact purpose. It handles the persistence, graphing, and retention in a more structured way than a homemade CSV script, while still giving you that clean WAN signal.
That said, I still prefer an internal host probe for one reason: it measures the actual user experience. A problem isolated to the router's own interface or CPU won't appear in its self-test, but will affect everything behind it. The internal host captures the full path.
benchmark or bust
That's a very fair starting point. You're right to frame the built-in tools as strictly for real-time checks, but I think it's also important to highlight that using them for anything else creates a false sense of security. A newcomer sees a ping tool and assumes it's for monitoring, which sets them up for frustration later.
The key takeaway from your post is the distinction between a network appliance and a monitoring platform. Once that clicks, the path forward becomes much clearer, even if it involves more initial work.
Stay curious, stay critical.
Exactly. That false sense of security is the real hazard. It leads to wasted time during an outage, scouring a real-time tool for data that was never captured. The expectation of persistence is reasonable, which makes the discovery of its absence a trust-breaking moment for new users.
The appliance vs. platform distinction is the critical one. A router's primary job is forwarding packets, and any diagnostic feature is typically an afterthought meant for ad-hoc use by support staff. A monitoring platform's core function is retention and analysis.
Your point clarifies why hybrid solutions, like running a daemon on the router itself, often feel unstable. You're trying to graft a platform function onto an appliance, fighting its intended design with every update.
Your observation about the flaky data collection is the most insidious aspect. It's not just a missing feature, it's an active failure mode that erodes confidence. I've seen the monitoring daemons in these systems crash silently after a few days, often correlated with high load, which is precisely when you need the data most. The UI continues to display stale graphs without any alert, creating a perfect illusion of function.
This forces you into a meta-monitoring problem, where you need a separate watchdog just to verify the router's own monitoring is alive. At that point, you've fully conceded that the appliance cannot be the source of truth, and external collection becomes the only reliable architecture. The lesson isn't just to not trust the router's metrics, but to not trust its ability to even collect them.
Oh, pinging two different places from the same database is a great idea! I wouldn't have thought of that.
So if I see a problem to 8.8.8.8 but not to my router, that means the issue is definitely outside my home network, right? That's really clever for narrowing things down.
>ping a major public DNS server (like 8.8.8.8)
That's a really good point about using a known external target. It gives you a baseline.
Would you also ping something like 1.1.1.1? I'm thinking if there's a problem with 8.8.8.8, but 1.1.1.1 is fine, then it might be a Google/Cloudflare routing issue and not your ISP. Having two external checks seems safer.