Gatus vs Uptime Kuma

Last reviewed Aug 24, 2026 · 535 words

Both watch your services and message you when something breaks, and both are excellent at it — the fork in the road is workflow, not capability. Uptime Kuma is a product: log into the web UI, click "add monitor", watch the live charts, state lives in SQLite. Gatus is configuration: one YAML file declares every endpoint, condition, and alert; the process reads it and serves a status page. It's the GUI-versus-GitOps argument in miniature, and you likely already know which side of it you live on.

What each does better

Kuma's strengths are immediacy and range: 90+ notification providers, monitor types covering HTTP, TCP, DNS, ping, Docker containers, and certificate expiry, a genuinely pleasant live dashboard (websockets throughout), and multiple styled public status pages. Adding a check takes fifteen seconds and no documentation — which is why the monitoring guide recommends it as the default first monitor.

Gatus's strengths are rigour and reproducibility. Checks are assertions, not pings:

endpoints:
  - name: immich
    url: https://photos.example.com/api/server/ping
    interval: 60s
    conditions:
      - "[STATUS] == 200"
      - "[BODY].res == pong"
      - "[RESPONSE_TIME] < 500"
      - "[CERTIFICATE_EXPIRATION] > 240h"

That file lives in git, deploys identically to any box, code-reviews like everything else, and rebuilds the entire monitoring setup from nothing in one docker compose up. There's no login because there's nothing to administer at runtime; the web UI is a read-only status page. At 64 MB with no database, it's the lightest serious monitor available — and its condition language (status, body JSON-path, response time, cert expiry, even IP) quietly does what Kuma needs its keyword-mode for, with more precision.

Operational differences that bite later

Kuma's state is its history: months of uptime data, but also a SQLite file to back up, a single instance by design, and a UI whose config can drift from what you remember setting. Gatus holds history in memory by default (add SQLite/Postgres storage if you want persistence across restarts) — its config can't drift because the file is the config, but your uptime graph starts fresh on redeploy unless you wire storage. Alerting philosophies mirror the split: Kuma offers every provider imaginable via clicks; Gatus covers the majors (ntfy, Slack, Telegram, email, PagerDuty, webhooks) via — of course — YAML. Both need so few resources that hardware is irrelevant; both should run somewhere other than the box they watch.

Decision table

What I'd do

Households and first-timers: Kuma, no argument — adoption beats architecture, and its dashboard earns wall-tablet status. If your homelab is already compose-files-in-git and you feel mild unease about config that lives in a database: Gatus, and enjoy monitoring that rebuilds itself. The genuinely defensible both-option: Gatus as the code-defined source of truth for checks, with its status page public — the two occupy so little RAM combined that the redundancy costs less than this paragraph.