Uptime Kuma is probably the best-loved self-hosted project in the monitoring space — roughly 90,000 GitHub stars, a genuinely fancy dashboard, unlimited monitors down to 20-second intervals, and 90+ notification integrations. If you have a spare server and want to own your monitoring end to end, stop reading and go run it; this page will say so again below.
The catch is in the first line of its own README: it is a self-hosted monitoring tool, and there is no official hosted version — the public demo wipes itself every 10 minutes, and the "managed Uptime Kuma" services you'll find are third parties charging monthly for a VPS with it preinstalled. So "free" Kuma really costs: a server, Docker (or Node.js ≥ 20.4 + git + pm2), a persistent volume, updates, backups — and, the part people learn the hard way, that server needs to live outside the infrastructure it watches. Kuma on the same box as your app means the outage that takes your app down takes the alerting down with it, silently.
This page is for when you don't have (or don't want) that second server: one curl arms a monitor checked from Cloudflare's network, with a webhook that fires once on down and once on recovery, plus a public status page, README badge and Atom feed. Nothing to install, nothing to update, no account. Small free capacity, honestly stated below.
Kuma's quickstart is docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data … on a machine you keep alive forever. Ours is:
curl -X POST https://mockbird.mockbird.workers.dev/api/status/monitor \
-H 'content-type: application/json' \
-d '{"url":"https://api.example.com/health","notify":"https://hooks.slack.com/services/T000/B000/XXXX"}'We GET your URL every 30 minutes (8s timeout, redirects followed, 2xx/3xx = up). Your URL is probed immediately and the response contains the result, a management secret, and three public artifacts:
No webhook handy? Both work webhook-less: omit notify and the create response includes a poll URL that returns the transitions since your last poll (plus the current state) — no endpoint to host. How poll mode works.
{
"id": "mon-XXXX",
"secret": "…",
"current": { "ok": true, "http_status": 200, "ms": 87 },
"checked_every_minutes": 30,
"status_page": "https://mockbird.mockbird.workers.dev/status/mon-XXXX",
"badge_svg": "https://mockbird.mockbird.workers.dev/status/mon-XXXX/badge.svg",
"feed_atom": "https://mockbird.mockbird.workers.dev/status/mon-XXXX/feed.xml"
}Kuma has status pages and badges too (good ones — multiple pages, mappable to your own domains). Ours are simpler: public but unguessable URLs, hostname-only, zero configuration. The badge drops straight into a README:
[](https://mockbird.mockbird.workers.dev/status/mon-XXXX)Kuma's notification list is one of its superpowers — Telegram, Gotify, ntfy, Matrix and dozens more. We support exactly three formats and sniff them from the notify host: hooks.slack.com gets Slack's {"text": …}, discord.com/api/webhooks gets Discord's {"content": …}, and any other HTTPS endpoint gets JSON signed with your monitor's secret (x-mockbird-signature: sha256=hex(hmac-sha256(secret, body)) — verify it like a Stripe webhook). That last one is the escape hatch: point it at your own relay and fan out to anything.
A confirmation delivery hits your webhook at create time, so you know the channel works before you rely on it. Alerting is deliberately quiet: one POST on down, one on recovery, debounced — two consecutive checks must agree, so a single blip never pages you.
Kuma's Push monitor type — your job pings a URL; missed pings mean trouble — is the dead man's switch pattern. Same idea here, no server:
curl -X POST https://mockbird.mockbird.workers.dev/api/status/heartbeat \
-H 'content-type: application/json' \
-d '{"name":"nightly backup","period_minutes":1440,"notify":"https://hooks.slack.com/services/T000/B000/XXXX"}'The response includes a secret ping URL; append && curl -fsS -m 10 <ping_url> to the cron job so it only checks in on success. Miss the period + grace and one service.down fires; resume and one service.up follows. Crontab/systemd/GitHub Actions recipes: cron-job monitoring with one curl.
| Uptime Kuma concept | Here |
|---|---|
| HTTP(s) monitor | POST /api/status/monitor {"url": …, "notify": …} — no server, no account; response includes the first check |
| Push monitor | POST /api/status/heartbeat — secret ping URL, period + grace, alert when pings stop |
| Notification providers (90+) | notify webhook — Slack/Discord auto-detected, anything else HMAC-signed JSON |
| Status page (multiple, custom domains) | /status/mon-XXXX — one per monitor, public, unguessable URL, hostname-only |
| Badge | /status/mon-XXXX/badge.svg — same README pattern |
| Dashboard | None — GET /api/status/monitor/:id?secret=… returns info, 24h ok-rate and recent checks as JSON |
| Docker volume, updates, backups | Nothing to maintain — and the monitor can't go down with your infrastructure |
| Watching public dev APIs | POST /api/status/watch — 52 already-tracked services (/status), free, no monitor slot |
Facts checked September 2026 against Uptime Kuma's official README — verify current details yourself:
| What you get | Pick it when | |
|---|---|---|
| Uptime Kuma | Free & open source, unlimited monitors, 20-second intervals, HTTP(s)/TCP/Ping/DNS/keyword/JSON-query/WebSocket/Docker/Push checks, 90+ notification services, multiple status pages on your own domains, cert-expiry info, 2FA, full data ownership. Requires: a server (Docker, or Node.js ≥ 20.4 + pm2), a persistent local volume (NFS unsupported), and ongoing updates — ideally on infrastructure separate from what it monitors. | You have a spare box outside the stack you're watching, want a real dashboard, fast checks, internal/LAN targets, or non-HTTP protocols. The best self-hosted option, full stop. |
| Mockbird | URL monitors: 3 live per IP (deleting frees the slot), 30 total, 30-min checks, HTTP GET only, public targets only. Heartbeats: 5 live per IP. Webhook + Slack + Discord alerts, status page/badge/feed per monitor — free, no account, no server. | You don't have a second server and don't want one; you want the alert armed this minute from a terminal, CI step, script or agent. |
Where Kuma wins, plainly: everything except the server requirement. Unlimited monitors to our 30-total cap, 20-second detection to our 30 minutes, TCP/Ping/DNS and friends where we only GET public URLs, LAN and private-network targets we can't reach, a dashboard we don't have, and complete ownership of your data. Our whole pitch is the second column of that table: no server, no signup, thirty seconds from curl to armed webhook — monitoring that lives outside your blast radius by construction.
# info + 24h ok-rate + recent checks · then stop
curl "https://mockbird.mockbird.workers.dev/api/status/monitor/mon-XXXX?secret=YOUR_SECRET"
curl -X DELETE "https://mockbird.mockbird.workers.dev/api/status/monitor/mon-XXXX?secret=YOUR_SECRET"Both endpoints self-document on a bare GET: GET /api/status/monitor and GET /api/status/heartbeat. The complete monitor walkthrough is the uptime monitor API guide; the commercial-tool comparisons are the UptimeRobot, Pingdom, Cronitor and healthchecks.io pages.