One Docker container gives you unlimited monitors, a status page, and notifications — the 2026 default answer to "we need uptime checks but not another subscription."
The full path from an empty server to monitors that page you. The notification step is the one that matters — a monitor nobody hears about is a dashboard, not monitoring.
On any host with Docker, run the container with a named volume — the volume holds every monitor, user, and notification setting, so it's the only thing you ever back up.
First load of the web UI walks you through creating the admin account. Do it immediately: until an account exists, anyone who can reach the port owns the instance.
docker run -d --restart=always \ -p 3001:3001 \ -v uptime-kuma:/app/data \ --name uptime-kuma louislam/uptime-kuma:1
Add an HTTP(s) monitor per site with keyword matching — checking that the page contains a known string catches the "server up, app broken" case a bare 200 check misses. Set the interval to 60s and retries to 2–3 so a single network blip doesn't page anyone.
Beyond HTTP: TCP monitors for databases and mail ports, DNS monitors to catch a nameserver or record change, and a certificate-expiry warning is built into every HTTPS monitor for free.
In Settings → Notifications add at least one channel — Uptime Kuma ships integrations for Slack, Telegram, email/SMTP, webhooks, and ~90 others. Attach the channel to each monitor (or set it as default so new monitors inherit it).
Test the channel with the built-in test button now, not during your first outage. If you use Slack, a dedicated #alerts channel with the webhook integration takes two minutes.
Status Pages → New Status Page, pick which monitors show, and you have a public page with uptime history. Map it to a subdomain like status.example.com by fronting the container with your reverse proxy and adding the DNS record.
Host the status page on different infrastructure than the sites it reports on if you can — a status page that dies with the thing it monitors is a common irony.
Put the admin UI behind your reverse proxy with TLS, and don't expose port 3001 raw to the internet. Enable 2FA on the admin account in profile settings.
Updates are a pull-and-recreate: docker pull the image, remove and re-run the container — the volume keeps everything. Back up the volume before major version jumps.
Monitor flaps up/down constantly.
Interval too tight with retries at 0, or the target rate-limits the checker. Set retries to 2–3 and back the interval off to 60–120s.
Notifications configured but nothing fires.
The channel exists but isn't attached to the monitor. Edit the monitor and tick the notification, or mark the channel as default and re-save monitors.
Status page shows raw IP instead of your domain.
Set the primary base URL in Settings → General, and front the container with a reverse proxy plus a DNS record for status.example.com.
All data gone after recreating the container.
It ran without the volume mount. Always run with -v uptime-kuma:/app/data; the data directory is the whole instance.
Checks pass from the server but users report downtime.
You're monitoring from inside the same network or box. Run a second instance elsewhere (a $4 VPS in another region) for an outside view.
Honesty note: articles are drafted with AI assistance, then a human checks each one against the vendor's current setup flow before it publishes — nothing goes live unreviewed. Vendor interfaces still change; if a step looks different, the underlying record is what matters.