I've been the sole on-site network admin at a multi-campus church for a few years now. Six locations, two of them out of state, a network I've been slowly modernizing, and no shortage of things that can quietly go wrong without anyone noticing until Sunday morning. This summer I finally set up an office, with it came a small rack, a spare M1 Mac Mini, and an excuse to build something I'd wanted for a while. A real-time status board I could glance at without opening a single dashboard.

Here's how it came together.

The hardware

An old M1 Mac Mini I already had, mounted in a small rack behind my desk, paired with an LG monitor sitting right below the network switch. The Mini's job is narrow on purpose: run a lightweight monitoring stack, act as a remote jump box when I'm off-site, and otherwise stay out of the way.

Setup was straightforward — wipe it clean with Erase All Content and Settings, update to the latest macOS before wiping (so it comes back current instead of needing a round of post-wipe updates), and build it around two accounts: an admin account for anything privileged, and a standard, unprivileged "viewer" account that auto-logs in and displays the board. Keeping the admin credentials off the screen that's visible to anyone walking by turned out to matter more than I expected once the box also started doubling as a remote access point.

Uptime Kuma

I run OrbStack on the Mini and pull Uptime Kuma as a single Docker container. Uptime Kuma does one thing well: up/down monitoring with clean status pages, and I didn't want to bend a heavier tool like Zabbix or CheckMK into doing a job Uptime Kuma already does well. (Those tools are still on my radar for actual metrics. Most likely bandwidth trending, SNMP polling switches, that kind of thing. Different job, different tool.)

The monitor list grew out from there:

  • Core services — the main website, our Rock RMS instance, Rock Check-in (arguably the highest-stakes item on the whole board, given what a Sunday-morning outage means), Google Workspace, our phone system, ticketing, MDM
  • Per campus — WAN circuits, the gateway, AV encoders and decoders for livestreaming
  • The VM and SQL database — that has Rock RMS installed onto it.

That last one turned into an unplanned debugging session. A ping test to the Azure VM's hostname kept failing in a way that looked like a firewall issue at first, until dig revealed the DNS label was resolving to 255.255.255.255 — the IPv4 broadcast address, not a real host. Not something I could fix on my end; a quick, specific message to the dev company managing that environment ("DNS is resolving to a broadcast address, not a valid IP") got it sorted. A good reminder that "it's not working" and "here's the exact thing that's wrong" are very different messages to send someone else's team.

Four audiences, one monitor pool

Uptime Kuma lets you build multiple status pages from the same underlying monitors, which turned out to be the right way to serve different audiences without maintaining three separate configurations:

  • A general staff page — website, Rock, check-in, and a single "is this campus online" indicator per site, nothing more technical than that
  • An IT-detail page — everything, down to individual WAN circuits and encoder/decoder status
  • A production-focused page — website, our streaming platform, AV hardware, campus status
  • A campus operations page — campus status and security NVR status

Building it this way meant adding a monitor once and then choosing which pages it shows up on, rather than keeping three lists in sync by hand.

Making it actually glanceable

The default Kuma theme is fine, but it's not built to be read from across a room. I wanted something closer to a real status dashboard — high contrast, a compact grid dense enough to show all six campuses without scrolling.

What's still ahead

A few things left on the list:

  • Finishing the remaining campuses' monitors
  • Exposing the general staff status page externally via Cloudflare Tunnel — no open ports on the firewall, just an outbound connection to Cloudflare's edge, with Access policies scoping exactly what's reachable from outside
  • A subdomain (status.eastside.com) delegated through Network Solutions' NS record feature, without touching the main domain's DNS
  • Deciding on a proper metrics platform (Zabbix vs. CheckMK) for the things Uptime Kuma isn't built for — bandwidth trends, SNMP-polled switch health, that kind of longer-horizon visibility

For now, though, the board does exactly what I built it to do: I glance up, and I know.