I used to guess whether my home network was healthy. SSH into the router, check the load, count the connected devices, check the ISP status, check the NAS. The guess work was the worst part. The actual checking took five minutes; the worry that I had missed something else ran in the background all day. Now I have a single dashboard on the kitchen wall that shows me everything in under two seconds. The build took a weekend. The maintenance takes about five minutes per month. The peace of mind is the real value.
Why a home network dashboard matters
The home network is the critical infrastructure that everyone in a household depends on and nobody monitors. The ISP goes down at 11pm. The NAS runs out of disk. The access point has too many clients. The smart home hub loses connection to its bridge. None of these are emergencies. All of them are annoying, and the path from “annoying” to “actually broken” is short.
A dashboard makes the invisible visible. I no longer have to “check whether the internet is up” because the kitchen tablet tells me. I no longer have to guess “is the NAS still running” because the green square is still there. The five minutes of attention per month is the cost. The savings in debugging time, and the sleep I get back, is the return.
The build is the kind of homelab project that justifies itself. Most homelab projects are fun to build and never used. The wall tablet is glanced at twenty times a day, catches problems before they become outages, and runs without me touching it. That is the bar to clear.
The stack
The build is four services and a wall tablet. The services are all open source and all run in Docker on a single homelab server. Home Assistant (a home automation platform) for the smart home devices, which I already had running. Glances (a system metrics tool that runs on every machine and exposes CPU, memory, disk, and network) on the homelab server, the NAS, and the router. Uptime Kuma (a self-hosted uptime monitor that polls services on a schedule) for service health checks. A custom HTML page that pulls data from all three and renders a single screen. The hardware is a $100 Amazon Fire tablet mounted on the kitchen wall in a $15 charging cradle. The Fire tablet runs a fully-kiosk browser app (a small Android app that locks the device into showing one URL) pointed at the static HTML page. The page refreshes every 30 seconds. Total hardware cost: $115. Software cost: $0. Time to build: about ten hours over a weekend. Time to maintain per month: about five minutes for container updates.
What the dashboard actually shows
The single screen has four quadrants. Each one is a colored card: green is healthy, yellow is warning, red is broken. The information density is high but the cognitive load is low. I look at the screen, parse the state in two seconds, move on with my day.
- Top left: ISP status and external IP. If this turns red, the internet is down. I know it before the rest of the household does.
- Top right: router connected clients and link speed. If this turns red, the wifi is degraded. I know to check the access point before everyone starts asking.
- Bottom left: the homelab cluster status. Number of VMs running, CPU and memory usage per node, last backup time. If this turns red, something is offline or starved.
- Bottom right: NAS disk space, smart home hub status, and the count of currently-active smart devices. If this turns red, the disk is full or the hub lost its bridge.
I tried a multi-page dashboard with drill-downs at first. Nobody used it. The wall tablet is single-purpose, the URL is a single page, the page is a single screen. The constraint forces the design, and the design works because it has no fat to trim.
The things I learned building it
Three lessons from the eight builds I have done for friends and family.
- The dashboard is only useful if it stays on one screen. Drill-downs are a power-user feature that nobody on a wall tablet wants. The single page is the constraint that makes the rest of the design work.
- Polling intervals matter. Glances polls every 30 seconds. Uptime Kuma polls every 60 seconds. Home Assistant pushes on state change. Polling too often taxes the source machines. Polling too slowly makes the dashboard feel stale. I settled on 30s for everything, which is fast enough to feel live and slow enough that the source machines do not notice.
- Self-healing is the whole point. The page refreshes every 30 seconds. If a service goes down, the next refresh shows the issue. The user never has to “reload” the page, never has to notice that something broke, never has to do anything to recover. The page just comes back green when the service comes back.
What it does not solve
The dashboard is read-only. It does not fix problems. It does not page me when something breaks. It does not take action when the NAS fills up or the UPS battery dies. For a homelab, read-only is fine. The kitchen tablet is for at-a-glance awareness, not for incident response.
For a small business, the right escalation from a read-only dashboard is Uptime Kuma with Slack or Pushover (a push notification service) for the things that need to wake you up, plus a proper monitoring stack like Prometheus and Grafana and Alertmanager for the things that need to wake someone else up. The wall tablet is the entry point. The alerting is a separate decision, and the alerting is the part that scales beyond a household.
When to build your own
The home network dashboard is worth building if you have at least three machines you care about (the router, the NAS, a homelab server or two) and at least one other person in the household who benefits from seeing the state. If the only machine is your laptop, the dashboard is overkill. If the only person is you, the dashboard is overkill too. If both conditions are met, the build is a weekend well spent.
The reference implementation above is the minimum viable version. The full version adds a second tablet in the home office, a weather widget, the family calendar, and a “last seen” timestamp for each smart device. The minimum viable version covers about 95% of the use case. The full version is for people who like tweaking the wall tablet the way other people like tweaking their home screens.
Trade-offs
The home network dashboard is not free in time. The first weekend is the big one, ten hours of build and debug and testing. After that, the maintenance is real but small: about five minutes per month for container updates, plus a half-hour per quarter to check that the Glances endpoints on each machine are still responding. The skill bar is moderate. You need to be comfortable with Docker, with editing HTML and CSS, and with reading Glances API output.
In my case, the trade-off has been worth it. The kitchen tablet catches problems before they become outages. The build is a one-time cost. The maintenance is a monthly chore that takes less time than the weekly “did the wifi go down again” conversations used to. Your math will be different if your homelab has more than ten machines, in which case a proper Grafana dashboard is the right next step, or if your homelab has fewer than three, in which case the wall tablet is overkill.
The migration took one weekend. The thing that was harder than expected was the kiosk browser setup on the Fire tablet. Amazon’s Fire OS does not let you set a default browser the way stock Android does, and the fully-kiosk app needed a $5 license to remove the watermark. The thing that was easier than expected was the Glances configuration. The default Glances settings on each machine are good enough for the wall tablet; I did not have to tune any thresholds.
If you have a homelab and a partner or family member who asks “is the wifi down” more than once a week, this is a clear win. If your homelab is a single Raspberry Pi running Pi-hole, look at the Pi-hole admin UI on a small screen and call it a day. If you have ten machines and a business, skip the wall tablet and go straight to Prometheus.
What I would tell past me
If I could send a message back to the version of me that started SSHing into the router to check whether the internet was up, I would say three things.
- Do not build a multi-page dashboard. A single screen with four colored cards is the only thing anyone actually looks at. Drill-downs are ego.
- Set the polling interval to 30 seconds and stop tweaking it. Faster is not better. Slower is stale. 30s is the sweet spot for a wall tablet the household glances at.
- Buy the kiosk browser license on day one. The free version of the fully-kiosk browser has a watermark that I tolerated for three months before I paid the $5. I should have paid on day one.