Lightweight Monitoring for a Home Lab That You Will Actually Maintain

Start with symptoms you care about

Monitor disk space, certificate expiry, container restart loops, and whether the public site responds over HTTPS. Fancy dashboards are optional; actionable alerts are not. Prefer Uptime Kuma (or similar) plus a weekly host cron — not a full Prometheus stack — unless maintenance time clearly exceeds the apps you are protecting.

If monitoring itself needs a cluster, you will not run it after month three. Prefer single-binary or compose stacks you can rebuild from backups in under an hour.

The minimum viable check list

Start with checks that map to real pain:

• **HTTPS user path** — `https://photos.example.com` not `container:2283` (cert expiry and proxy misconfig hide from internal pings).
• **Disk free > 15%** on every volume that holds databases or uploads.
• **Container restart loop** — `docker ps --filter status=restarting` in cron.
• **Backup job exit code** — restic/Borg last run non-zero pages louder than "last successful 30 days ago."
• **TLS cert expiry < 14 days** — ACME silent failure happens.

# weekly cron on the Docker host — good enough for many homelabs
df -h | awk 'NR>1 && $5+0 > 85 {print}'
docker ps --filter status=restarting --format '{{.Names}}'

Uptime Kuma compose fragment

Run Kuma on the same host or a tiny VPS for external perspective:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1.23.15
    volumes:
      - ./kuma-data:/app/data
    ports:
      - "127.0.0.1:3001:3001"
    restart: unless-stopped

Expose the UI through the reverse proxy with auth; do not publish 3001 to WAN raw. Notification channels: one primary (Telegram or email), one backup — not six duplicates.

[Add real environment details here]
Host for Kuma:     (same Docker host / separate VPS)
Kuma image tag:    (pinned)
Monitors count:    (N)
Primary notify:    (Telegram / email / …)

Choose notification channels wisely

Email, Telegram, or a push service can work. Avoid ten channels for the same alert. If everything pages you, you will silence everything — then real outages hide in notification debt.

Severity routing example: Telegram for DOWN, weekly email digest for DEGRADED (backup lag < 24h). Midnight pages require a human-scale incident, not a single missed ping unless it repeats.

Separate "down" from "degraded"

A paused backup job is degraded; an unreachable reverse proxy is down. Severity labels help you respond proportionally at midnight. Document which checks are allowed to wait until morning — and which mean drop everything.

Operator note: treating backup lag as DOWN for weeks trains people to ignore alerts. Prefer DEGRADED with an explicit lag threshold you can live with.

External perspective matters

Run at least one monitor outside the LAN. Hairpin NAT and split DNS hide "works on my Wi‑Fi" failures from everyone else. A small VPS running Kuma checks against public URLs is cheap insurance — ties directly to VPS vs home lab split patterns.

Pick a monitoring depth (and stop there)

Tier 0 — host disk + SMART + certificate end-date cron. Tier 1 — blackbox HTTPS checks from outside the LAN (Kuma or similar) on a short URL list. Tier 2 — Prometheus-style metrics only when you have multiple hosts or repeat performance mysteries.

Stay on tier 0–1 for a single Compose box and a small household. Add tier 2 only after the same performance mystery hits twice without data. Hybrid that works: tier 1 for user-visible URLs, tier 0 for disk, node metrics on the hypervisor only — not exporters on every container.

# weekly TLS end-date check (adjust hostnames)
for h in photos.example.com vault.example.com; do
  echo | openssl s_client -connect "$h:443" -servername "$h" 2>/dev/null \
    | openssl x509 -noout -enddate
done

Keep monitoring simple to deploy

Backup Kuma's `/app/data` volume with the rest of ops config. Export monitors as JSON after changes. When rebuild time exceeds one hour, simplify — you are monitoring a household, not a Fortune 500 SRE team.

Review alerts monthly

Delete noisy rules. Add missing ones discovered during incidents. Monitoring is a living checklist, not a one-time install. Monthly ritual: read the last 30 days of alerts, delete any that fired more than five times without action, add one check that would have caught the most annoying recent surprise.

Related reading

See Automatic SSL certificates, Restore drill playbook, VPS vs home lab, and Secure remote access.