A home lab gets harder to understand as it grows. When a dashboard stops loading, is the application down, the Pi offline, or the network misbehaving? Uptime Kuma gives you a small, readable record of whether your services respond.

Start by monitoring two things you care about, then deliberately interrupt one. A notification you have actually received is more useful than a dozen green indicators you have never tested.

Choose what you want to know

An HTTP check answers whether a web endpoint responds. A TCP check answers whether a port accepts a connection. A ping check answers a narrower reachability question. None of them alone proves that every feature of an application is healthy.

Use a Pi 4 or 5 with 64-bit Raspberry Pi OS and local storage. Install Docker Engine and the Compose plugin from the official Debian instructions if they are not already available. This guide assumes sudo docker compose version succeeds.

Start Uptime Kuma with persistent data

Create a project directory and a Compose file. The named volume preserves configuration across container replacement. Uptime Kuma's project documentation specifies local storage; do not place its live data on an NFS share.

BASH
mkdir -p "$HOME/uptime-kuma"
cd "$HOME/uptime-kuma"
nano compose.yaml

Save this configuration, which follows the project's current version-2 container line:

YAML
services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - uptime-kuma-data:/app/data
volumes:
  uptime-kuma-data:

Check the rendered configuration and start the service. The published port is reachable on the host's interfaces, so keep it behind your trusted network boundary rather than creating a public router forward.

BASH
sudo docker compose config
sudo docker compose up -d
sudo docker compose ps
sudo docker compose logs --tail=50

Open http://PI_ADDRESS:3001 from your local network and create your account. Save the login details securely before adding monitors.

Add two checks with different jobs

First, add an HTTP monitor for a noncritical web service you control. Use its actual address on the network. Inside a container, localhost refers to that container, not to every service running on the Pi.

Next, add a TCP check for a different service, such as your Pi's SSH port. Name the monitors for what they test: “Workshop dashboard HTTP” is clearer than “Server.” Add a note explaining where the service runs and what a failure should mean.

Start with a moderate interval such as 60 seconds and require more than one failed check before alerting if the monitor supports that configuration. Tune based on observed behavior, not on a desire for the smallest possible number.

Prove an alert can reach you

Configure one supported notification channel and use its test function. Then stop the noncritical service you chose, wait for the expected failure, and restore it. Confirm you receive both the outage and recovery information you intended.

Do not perform this experiment with your household's only DNS server or an active print job. Choose a disposable service or schedule a maintenance window. Record the delay between stopping it and receiving the alert so your expectations match the configuration.

Know the monitor's blind spots

A monitor running on the same Pi as an application cannot send a useful alert after that Pi loses power. Put the monitor on another machine if host failure is what you need to detect. A local monitor also cannot tell you exactly what a visitor on the public internet sees.

Back up the data volume while the service is stopped for a consistent copy, and record the container version. Test updates between other maintenance tasks so you can distinguish a monitoring change from an application failure.

Turn status into a useful routine

Review repeated brief outages before adding more notifications. They may reveal unreliable Wi-Fi, a restarting service, or an overly aggressive timeout. A quiet monitor with meaningful alerts is easier to trust.

Pair availability checks with host metrics through Open Pi: CPU, memory, temperature, and storage help explain why a reachable service is slow. For checking the dashboard away from home, use the Tailscale remote-access guide.

Sources and further reading

About this guide

Researched from the official documentation linked above on September 10, 2026. Setup examples are starting points and have not been hardware-tested by Open Pi. Check your board, OS, and the project’s current instructions before installing.