A dashboard built for the wall

The situation

The operator's monthly service report listed switch availability per station, microwave links, CCTV and biometrics. The live view in the centre was a generic monitoring tool, full of IP addresses and alert noise the client did not need. The brief was short: do for this client what the ISP dashboard does. Status with plain reasons, availability, client-visible known issues, topology, and no IPs in the client view.

What we did

First a registry. A station is its switch. Each camera, reader and fare gate is placed on a station by the least-populated switch port that learned its MAC address, with name matching as the fallback and a reviewed overrides file for the rest.

Then the measurement rules, written in the code and shown on the page so nobody has to guess what a number means. A device is down after ten minutes. An outage of fifteen minutes or less that starts in a five-minute slot where sixty or more devices failed together is a monitoring artefact and is excluded, though staff still see it raw. A device that has never been polled is unverified and excluded. Three or more station switches down within fifteen minutes is one upstream event, not three. Anything down for more than thirty days is folded away on the overview.

It runs on its own nginx virtual host with its own certificate, a SELECT-only database user into the monitoring system, and one-time sign-in links. Later additions: field teams drawn from the WhatsApp groups where the work is actually coordinated, a fibre-fault tool that starts from the diagram rather than a form, job-card threads, and reason-for-outage documents generated from them.

What changed

The dashboard is on the video wall. Because of that we treat it as mission-critical: verify locally, smoke-test, then deploy, and say so before anything risky.