← BACK TO THE SIMPLE VERSION
PROPER INSTRUCTIONS

Build a network monitoring dashboard: proper instructions

A home dashboard should answer actionable questions: is the gateway reachable, is DNS working, did a service stop, and did latency change? Colourful graphs alone are not monitoring. This guide deploys Uptime Kuma on Debian for lightweight availability checks and alerts. It sees the network from one LAN point, so it cannot prove what users elsewhere or outside the home see.

Define monitors before installing software

Make an inventory containing a router gateway, an external DNS address, the DNS filter, an important server and each key internal web service. For every target, write its owner, expected response and first action when it fails. Avoid monitoring every low-value smart device; alert fatigue makes genuine incidents easier to miss.

Target Test Failure suggests
LAN gateway Ping Local routing or power issue
External resolver Ping or DNS Possible ISP or upstream fault
DNS filter DNS lookup Filtering unavailable
Web application HTTP status Application or proxy fault

Prerequisites and installation

Use a patched wired Debian host with a DHCP reservation, 2 GB RAM and storage backed up elsewhere. A separate host improves visibility when the main server is down. Install current Docker Engine using Docker’s official Debian instructions; do not casually mix distribution and upstream Docker packages. Verify it: 

sudo systemctl is-active docker
sudo docker run --rm hello-world

.

  1. Create protected persistent storage: 
    sudo install -d -m 750 /srv/uptime-kuma

    .

  2. Create /srv/uptime-kuma/compose.yaml with this minimal configuration. Review image updates rather than blindly treating a dashboard as disposable: 
    services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - ./data:/app/data

    .

  3. Start and inspect it: 
    cd /srv/uptime-kuma
sudo docker compose up -d
sudo docker compose ps
sudo docker compose logs --tail=50 uptime-kuma

    .

  4. Open http://SERVER_IP:3001 from the LAN and create a unique administrator password. Do not create a public status page merely to see a private household dashboard.

Build and test monitors

  1. Add a ping monitor for the gateway. Its failure means the dashboard cannot reach it, not necessarily that the router is dead.
  2. Add a DNS monitor that asks the DNS filter for example.com. This proves resolution, not merely host reachability.
  3. Add HTTP monitors for internal services with expected status codes. Prefer a health endpoint containing no personal data. A login page returning 200 proves only a limited part of an application.
  4. Add an external target. Gateway success with external failure helps distinguish a WAN issue from a local outage.
  5. Start with 60-second intervals and two or three retries. That reduces alerts for brief outages. Use longer intervals for slow or battery devices.
  6. Configure one private alert channel and use its built-in test. Then monitor an unused local port or temporarily pause a non-critical test service to prove both down and recovery messages arrive. Do not unplug the main router during important use.
  7. Restart the stack and ensure history persists: 
    sudo docker compose restart
sudo docker compose ps

    . If history disappears, correct the volume mapping before continuing.

Operations, security and rollback

Keep port 3001 LAN-only or use a maintained VPN for remote access. Do not port-forward the raw dashboard. Monitoring data reveals hostnames, topology and outage history, so limit administrator accounts and do not store arbitrary credentials in monitor fields. Docker-published ports can bypass simplistic firewall expectations; inspect listeners after every change: 

sudo ss -tulpn
sudo docker ps
df -h /srv/uptime-kuma

.

Back up /srv/uptime-kuma/data using a documented consistent method, then restore it into a separate test path. Before upgrades, take or verify a backup, read release notes, update one component and perform a smoke test. To roll back, stop the stack, restore verified data if needed, return to the previously reviewed image reference and start it. To remove it, export or back up needed configuration, run 

cd /srv/uptime-kuma
sudo docker compose down

, then delete persistent data only after confirming no alerting dependency remains.

Make the dashboard useful over time

Review each alert after the first month. If it did not lead to a useful action, change the check, interval or notification policy rather than simply silencing it. Record planned maintenance windows where the dashboard supports them, so a known reboot does not look like an incident. Keep a small incident note: time, affected target, symptoms, diagnosis and fix. Patterns such as repeated WAN loss or a filling disk are more valuable than a single red badge.

Availability checks have blind spots. A ping can succeed while an application is unusable; an HTTP 200 response can come from an error page; a dashboard on the same switch can be unable to distinguish a switch failure from its own isolation. Add deeper checks only when they answer a real operational question, such as a DNS lookup for a resolver or a lightweight authenticated health endpoint for a service. Never place an administrator password in a plain URL or monitor label. Store sensitive monitor credentials only through the dashboard’s protected mechanism, limit their permission, and rotate them when access changes.

Check dashboard resource use after adding monitors. Excessively frequent checks against cloud services can trigger rate limits and waste bandwidth. Establish a backup test after an upgrade and a quarterly restore test for configuration data. Maintain an alternative way to receive critical notifications, because an alert channel that relies on the failed service may be unavailable precisely when needed.

Simple fault-isolation routine

  1. Read the alert history and identify whether the gateway, DNS and application checks failed together or separately.
  2. Run the corresponding direct check from the dashboard host, then from a client, before restarting equipment. This preserves useful evidence.
  3. Check recent changes, power and cabling. Restart only the smallest affected component, then confirm both recovery and alert delivery.

Do not use a dashboard restart as the default answer to an alert: it can erase the distinction between a monitor fault and a genuine network fault.