Out-of-Band Infrastructure Monitoring: Deploying Uptime Kuma & AutoKuma on an External VPS

Hosting an uptime monitoring dashboard inside your own homelab creates a fatal blind spot: when your home power trips, your router crashes, or your residential ISP goes down, your internal monitor goes dark alongside everything else—and is incapable of alerting you.

True infrastructure reliability requires out-of-band monitoring: deploying Uptime Kuma on an independent external cloud VPS. By pairing Uptime Kuma with AutoKuma, you achieve declarative GitOps observability—managing all HTTP, TCP, keyword, and push monitors as version-controlled .toml files in Git with instant alert routing via Ntfy.

⚡ Quick Runbook: 60-Second Implementation

TL;DR: Deploy Uptime Kuma with AutoKuma declarative GitOps synchronization:

# compose.yaml
services:
  uptime-kuma:
    image: louislam/uptime-kuma:1.23.16-alpine
    container_name: uptime-kuma
    restart: unless-stopped
    security_opt:
      - no-new-privileges:true
    volumes:
      - ./data:/app/data
    networks:
      - monitor-net
      - proxy-tier

  autokuma:
    image: ghcr.io/bigboot/autokuma:2.1.0
    container_name: autokuma
    restart: unless-stopped
    depends_on:
      - uptime-kuma
    environment:
      AUTOKUMA__KUMA__URL: http://uptime-kuma:3001
      AUTOKUMA__KUMA__USERNAME: "@/run/secrets/kuma_user"
      AUTOKUMA__KUMA__PASSWORD: "@/run/secrets/kuma_pass"
      AUTOKUMA__KUMA__CONNECT_TIMEOUT: 20
      AUTOKUMA__DOCKER__ENABLED: "false"
      AUTOKUMA__STATIC_MONITORS: /monitors
      AUTOKUMA__DEFAULT_SETTINGS: |
        http.max_retries: 3
        http.retry_interval: 60
        keyword.max_retries: 3
        keyword.retry_interval: 60
    secrets:
      - kuma_user
      - kuma_pass
    volumes:
      - ./monitors:/monitors:ro
      - autokuma-data:/data
    networks:
      - monitor-net

volumes:
  autokuma-data:

secrets:
  kuma_user:
    file: ./secrets/kuma_user.txt
  kuma_pass:
    file: ./secrets/kuma_pass.txt

networks:
  monitor-net:
  proxy-tier:
    external: true

1. The Problem with In-Band Monitoring

If Uptime Kuma lives on your home server, it can only notify you if a single application container fails while the server, router, and internet remain healthy. In major outage scenarios (ISP outages, hardware lockups, core network switch failures), your in-band monitor is dead.

By hosting Uptime Kuma on a low-cost external VPS (e.g. HostUS or Oracle Cloud Free Tier), the monitor sits outside your local network. It validates edge ingress (Cloudflare Tunnels, Tailscale Funnels, public DNS), tests actual internet accessibility, and reliably fires mobile push notifications when your home connection drops.

2. Declarative Monitoring with AutoKuma

Clicking buttons in the Uptime Kuma web interface to create dozens of monitors is tedious, error-prone, and impossible to version control. AutoKuma bridges Uptime Kuma with GitOps.

AutoKuma continuously watches a local ./monitors folder containing declarative .toml definitions. When you commit and push a new file, AutoKuma creates or updates the monitor via API within seconds.

Example: Group Monitor (Parent Node)

# monitors/homelab-group.toml
type = "group"
name = "Home Infrastructure"

Example: Keyword Health Check

# monitors/vaultwarden.toml
type = "keyword"
name = "Vaultwarden Passwords"
parent_name = "Home Infrastructure"
url = "https://vault.example.com/alive"
keyword = "alive"
interval = 60
max_retries = 3

Example: Edge Healthcheck Endpoint

# monitors/auth-pocket-id.toml
type = "http"
name = "Pocket-ID Auth"
parent_name = "Home Infrastructure"
url = "https://auth.example.com/healthz"
interval = 60

3. Flap Dampening and Alert Routing

Transient network hiccups should not trigger alerts. AutoKuma enforces global retry thresholds:

max_retries: 3 combined with retry_interval: 60 requires a monitored service to continuously fail for 3 minutes before changing state to DOWN. This guarantees container restarts or brief ISP renegotiations do not trigger false alarms.
Alerts are dispatched immediately to Ntfy or Pushover with priority flags and direct links to the failing service.