THE NAME
Why “HopWarden”?
Everything your network sends travels in hops — little jumps from one box to the next, all the way out to the internet and back. Most of the time, nobody is watching those hops. They just leave. Unsupervised. Into the void.
That felt irresponsible, so we hired a warden. HopWarden stands at the edge of your network with a clipboard and a faintly disappointed expression, counting every hop on the way out and every hop on the way back, and clearing its throat the moment one fails to return. Packets behave when someone is watching.
We did audition other names. “PacketPolice” sounded litigious. “NetNanny” was taken, and judgmental. “The Bouncer” tested well until people asked where the club was. “HopWarden” stuck — equal parts hop (the thing it watches) and warden (the thing it is): patient, a little stern, and never once asleep at the counter.
WHO IT IS FOR
HopWarden isn’t built for IT.
I built this with my mom in mind. She isn’t technical, and if the internet goes down at her end I want her to be able to look at one thing and know that, without calling me first.
That’s the whole design constraint. Most network tools assume there’s somebody on the payroll who knows what a subnet is. At a feed store, a fuel counter, a small clinic, that person doesn’t exist, so when something breaks it starts with a thick manual and a list of phone numbers, hoping someone on the other end knows what to do.
So HopWarden is a screen, not a console. A small operator only has a handful of things that have to keep working: three, maybe six. It watches those and nothing else, and when one of them stops answering it says which one, in plain words. There’s nothing to learn and nothing to log into.
If the person at the register can tell in a couple of seconds whether the problem is theirs or somebody else’s, it worked.
IT DOESN’T SHUT IT OUT EITHER
Built for the counter. Open to the server room.
Every unit answers on the machine itself. Ask it for its status and you get the live picture as JSON: whether the link is up, which WAN is carrying traffic, and every destination with its loss, latency, quality score, trend and certificate days remaining.
GET http://localhost:8253/status
That works without an account, so a script can ask “is the internet OK here” and get a straight answer back. Enrolled units also expose a Prometheus endpoint and can listen beyond the local machine, for the operator who already has a dashboard and wants this in it.
GET http://localhost:8253/metrics enrolled units
The gate is whether the unit is enrolled. There is no licence key and nothing nags you. Both endpoints are read-only, answer GET only, and echo nothing back from the request.
WHY EVERY STATION WANTS ONE
Less downtime, fewer wrong phone calls, real evidence.
A red ring, an on-screen banner and an alert email the moment a service fails, not when the line at the register starts complaining.
Each service is tracked separately, so the screen tells "the payment host is down" from "the internet is down" from "our own link dropped."
Monthly uptime is computed per service against an SLA target: tamper-evident evidence for a billing dispute with an ISP or processor.
Scheduled PDF reports arrive by email: daily, weekly or monthly, up to 10 recipients. Set it and forget it.
Predictive analytics warn of declining device health or an SLA trend heading toward breach, days before it becomes an outage.
The same platform rolls every site into one fleet dashboard with per-site uptime, incident tracking and a health scorecard.
WHEN IT BREAKS, IT WRITES IT DOWN
Evidence you can hand to somebody.
The moment a destination stops answering, the unit records the route to it, hop by hop. You get the state of the path at the time of the failure instead of a description of it from memory.
Every outage, how long it lasted and the measurements around it stay in the unit’s own log. One click turns that into a printable dispute pack: the document you attach when a provider tells you they saw nothing wrong. It works whether or not the unit is enrolled.
HOW HOPWARDEN STARTED
Troubleshooting the one thing that wasn’t broken.
Some time ago I was at the feed store, cash only, with a long line at the register that was hardly moving.
The credit card machine was down, timing out. The staff spent the whole outage on the phone with the home office troubleshooting the payment terminal. “Try again” would come over the speakerphone every couple of minutes, and every couple of minutes the terminal came back with “host not available”.
They were troubleshooting the one thing that wasn’t broken. A network error had shown up on a payment terminal, and the non-technical staff had no way to read the cryptic message they were being shown. I never found out how it got resolved. I gave up and left empty-handed, but with an idea.
What if there was a small device, or an application, that let non-technical people pinpoint where the problem actually is?
HopWarden was built for that gap. It sits on the counter, monitors the handful of services the business actually runs on, measures them from the store’s side of the connection, and when one fails, it says which one.