Uptime Kuma
Up and down checks for every service, probing 127.0.0.1 from host networking, with alerts that actually arrive.
Names and addresses are placeholders. The list says what each one stands for.
What it does here
Uptime Kuma checks each service on a schedule and sends a message when one goes down. The alert is the point. A status page nobody watches doesn't help.
Canonical setup
One container with a data folder. Set the admin account, add a monitor per service, set up a notification channel, and attach it to every monitor.
Upstream: Uptime Kuma.
In this build
- Host networkingThe services bind to 127.0.0.1, and only a container on the host network can reach the host's loopback.
- Monitors on 127.0.0.1, not localhostForgejo on 3000, Dockge on 5001, Beszel on 8090.
- Email alerts through the shared relaySee the msmtp card.
- Served by Caddy as status.dev.tailnet.exampleIt listens on 3001.
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: unless-stopped
network_mode: host
volumes:
- /srv/data/uptime-kuma:/app/dataSeams
Where this meets the rest of the build. Each one leads with what you will actually see.
Symptomconnect ECONNREFUSED ::1:3000
localhost resolves to the IPv6 address ::1 first, where nothing listens. Write monitors as http://127.0.0.1:3000.
Symptomevery monitor shows down
In a bridge container, 127.0.0.1 is the container itself. Run Uptime Kuma on host networking.
Symptoma service is down and nobody hears about it
A notification channel does nothing until it's attached to each monitor. Attach it, and send a test.
Verify
Every monitor is green. Stop one container with docker stop dockge, wait for the alert to arrive, then docker start dockge.
- 17 Oct 2026First written.