Uptime Kuma vs Gatus (2026): Which Should You Self-Host?

If your VPS runs anything worth waking up for, you need self-hosted uptime monitoring that pages you before your users do. The uptime kuma vs gatus question is the first fork in that road. Both are free, open source, single-container blackbox probers, and both will ping you at 2 a.m. when the blog or the API dies. This comparison uses the 2026-era versions: Uptime Kuma 2.5.3 (August 2026) and Gatus v5.37.0 (September 2026), checked against the upstream projects on 27 September 2026.

The one-sentence difference: Uptime Kuma is a click-ops monitor with a beautiful status page. Gatus is YAML-defined monitoring for people who keep infrastructure in git. Everything else follows from that.

If you arrived looking for an uptime kuma alternative after watching a SQLite file eat a disk, or after a “gatus vs uptime kuma reddit” thread that ended in “both are fine, pick one”, this is the operator version. Both tools installed with Docker Compose on a small VPS, the same five monitors configured in each, the failure modes nobody covers, and a blunt decision rubric.

The services you run are what the monitor watches. Maybe you are self-hosting Jellyfin on a VPS alongside a Git forge, a couple of side projects, and a nightly backup. If that box already runs a self-hosted PaaS like Coolify, Dokploy or Kamal 2, the monitor slots in beside it on the same Docker network.

Below: the 10-second verdict table, two working installs behind a reverse proxy, side-by-side configs, and what breaks six months in.

Uptime Kuma vs Gatus at a glance

The 10-second answer first. Both tools probe from the outside (the same job UptimeRobot does, minus the SaaS). The real difference is who writes the config and where it lives.

Quick pick:

If you have used either tool before, nothing in that table should shock you. Uptime Kuma won the adoption race because clicking “New Monitor” is a 30-second job and the status pages look client-ready out of the box. Gatus won the git crowd because the entire monitoring config is one reviewable file. The r/selfhosted threads that argue this (“gatus vs uptime kuma reddit” gets you there) boil down to workflow, not quality.

One cost note up front: both are free with no required paid tier. Kuma is donation-funded, Gatus has an optional managed offering you can ignore. The whole bill is a slice of a $4-6/month VPS and some disk. Which slice you want to own is the rest of this article.

Two philosophies: a web UI vs YAML in git

Kuma is UI-first. You click monitors into existence, they live in SQLite, and the dashboard streams live updates over WebSocket. Backup means copying the data/ directory. Your monitoring config is not diffable and not reviewable, and if that database file corrupts with no backup, you rebuild every monitor by hand.

Gatus is config-as-code. The entire monitoring setup is one config.yaml (the gatus yaml config you commit), hot-reloaded when it changes. Review monitor changes in pull requests, revert them with git revert, and restore the whole thing onto a fresh box with git clone. Results go to SQLite or Postgres; the dashboard is read-only. It looked weak next to Kuma for years, but a UI refresh in the v5 line closed most of that gap, and users on r/selfhosted rate the current dashboard well.

Uptime Kuma versus Gatus architecture: browser UI and SQLite on the left, git-managed YAML and Gatus on the right

Both are blackbox probers. They check from the outside whether a URL answers, a port connects, a cert is valid. That is a different job from node metrics or traces, which is why both are closer to UptimeRobot than to a Prometheus node exporter. Gatus’s README makes this case explicitly: metrics pipelines go quiet when no traffic reaches an app, while a blackbox check keeps probing.

Installing Uptime Kuma v2 with Docker Compose

Before you start:

1 vCPU and 1 GB RAM is enough for either tool at this scale. Any cheap box works: a small Hetzner Cloud VPS, the box your Dokploy stack already lives on, a spare mini PC. No database container is required.

The README path pulls the compose file and starts the stack:

mkdir uptime-kuma && cd uptime-kuma
curl -o compose.yaml https://raw.githubusercontent.com/louislam/uptime-kuma/master/compose.yaml
docker compose up -d
# dashboard on http://localhost:3001 (first run creates the admin account)

If you prefer one command, and you want the port bound to localhost because a proxy will front it:

docker run -d --restart=always \
  -p 127.0.0.1:3001:3001 \
  -v uptime-kuma:/app/data \
  --name uptime-kuma louislam/uptime-kuma:2

Verify the install:

docker compose ps        # or: docker ps --filter name=uptime-kuma
curl -I http://localhost:3001

You want HTTP/1.1 200 from curl (a 302 to the setup page on first run is also fine), then open the dashboard, create the admin account, and turn on 2FA (TOTP) while you are in there. A “container running but curl hangs” usually means the process is still migrating data. Check docker compose logs -f.

Uptime Kuma dashboard: monitor list on the left, a Google DNS monitor detail with heartbeat bar, ping stats and a response-time graph on the right

Upgrading from v1: the move to v2 is one-way and it rewrites the heartbeat table. If you have an existing instance, the Uptime Kuma v1 to v2 migration wiki is the source of truth. Short version:

docker compose down                  # 1. stop
cp -a /path/to/data /backup/data     # 2. back up the data dir (the wiki says: do it three times)
# 3. change the image tag to louislam/uptime-kuma:2
docker compose up -d
docker compose logs -f               # 4. watch the migration; do NOT interrupt it

Two more v2 traps worth knowing before you upgrade: Debian/Raspbian Buster hosts hit a libseccomp2 bug and must not be upgraded in place, and non-Docker installs now need Node.js 20.4 or newer. Rootless images exist, but the wiki does not recommend using them for a v1 to v2 upgrade.

Installing Gatus with Docker Compose

The Gatus install is one container and one YAML file. The two launch methods differ only in who manages the process.

mkdir gatus && cd gatus && mkdir config data
$EDITOR config/config.yaml    # paste the config below
docker run -d --name gatus --restart=always \
  -p 127.0.0.1:8080:8080 \
  --mount type=bind,source="$(pwd)"/config,target=/config \
  --mount type=bind,source="$(pwd)"/data,target=/data \
  ghcr.io/twin/gatus:stable

services:
  gatus:
    image: ghcr.io/twin/gatus:stable
    restart: always
    ports:
      - "127.0.0.1:8080:8080"
    volumes:
      - ./config:/config
      - ./data:/data
    environment:
      - GATUS_CONFIG_PATH=/config/config.yaml

docker compose up -d

The config file is where Gatus lives. This trimmed config/config.yaml covers storage, alerting, and two endpoints:

storage:
  type: sqlite
  path: /data/data.db      # default is memory; history gone on restart

alerting:
  telegram:
    token: "123456:ABC-DEF..."
    id: "0123456789"
    default-alert:
      failure-threshold: 3
      send-on-resolved: true

endpoints:
  - name: bitdoze
    group: public
    url: "https://bitdoze.com"
    interval: 60s
    conditions:
      - "[STATUS] == 200"
      - "[RESPONSE_TIME] < 800"
      - "[CERTIFICATE_EXPIRATION] > 336h"   # fail the check at under 14 days left

  - name: postgres
    url: "tcp://db.internal:5432"
    conditions:
      - "[CONNECTED] == true"

A few config details that save debugging time: ${ENV_VAR} substitution works in the YAML (escape a literal dollar sign as $$, which bites when you paste webhook URLs with $ in them), GATUS_CONFIG_PATH points at a non-default config file, YAML anchors work for shared defaults, and [DOMAIN_EXPIRATION] checks refuse intervals tighter than 5 minutes to stay clear of WHOIS rate limits.

Verify the install:

docker compose ps
curl -I http://localhost:8080

Open the dashboard and confirm both endpoints from the config are listed and green. Then edit config/config.yaml (add a comment) and check docker compose logs for a reload message. That round trip proves hot reload is actually watching the directory.

Gatus health dashboard: a grid of endpoint cards with Healthy or Unhealthy badges, heartbeat bars and response times per endpoint

Sizing aside: the same 1 vCPU / 1 GB VPS runs this comfortably, and if you are shopping for a second box to keep monitoring separate from production, a budget Hostinger VPS does the job. ICMP checks inside containers needed CAP_NET_RAW on Gatus versions before v5.31.0; since v5.31.0 unprivileged ping works unless you run the container as root.

Putting both behind a reverse proxy

The deployment shape on this stack is boring on purpose: Docker on the VPS, Caddy or Traefik or Nginx in front with TLS, and both tools bound to 127.0.0.1 in compose so nothing answers on the public interface. Do not publish 3001 or 8080 to the internet and call it done; both dashboards deserve auth plus TLS plus a firewall.

Rollback is trivial. Change the port mapping back to 8080:8080, restart, and curl http://localhost:8080 works again. Nothing inside either tool knows or cares about the proxy.

Uptime Kuma needs WebSocket support

The live UI rides a long-lived Socket.IO WebSocket. Proxies that cut idle connections make the dashboard look frozen: the page loads, then nothing updates. Set read timeouts to 3600 seconds or more on the proxy route (the reference Nginx and Traefik configs for Kuma both do this), and make sure the proxy forwards Upgrade and Connection headers.

Verify: open the dashboard through the public hostname, trigger a test check, and watch the heartbeat bar move without a page reload.

Gatus needs its own subdomain

Gatus does not support path-based routing. status.example.org works; example.org/status/ does not (see the FAQ in the Gatus README and issue #88). Plain HTTP proxying is enough, no WebSocket requirement.

Verify: browse to the subdomain and see the dashboard with live-check results. That is the whole test.

The same five monitors, configured twice

Feature matrices lie by omission. Here is one realistic solo-operator stack configured in both tools so you can compare the experience: a public site, an API with a JSON health endpoint, Postgres on an internal hostname, a TLS cert you care about, and a nightly backup job stuck behind a firewall. Same five monitors, two philosophies.

HTTP checks with keyword and JSON body conditions

endpoints:
  - name: bitdoze
    group: public
    url: "https://bitdoze.com"
    interval: 60s
    conditions:
      - "[STATUS] == 200"
      - "[RESPONSE_TIME] < 800"

  - name: api-health
    group: public
    url: "https://api.example.com/health"
    interval: 60s
    conditions:
      - "[STATUS] == 200"
      - "[BODY].status == ok"
      - "len([BODY].dependencies) > 0"

Response-time assertions map to Kuma’s “Max. response time” field versus Gatus’s [RESPONSE_TIME] < 800 condition line. Same intent, different surface.

TCP port checks

  - name: postgres
    group: internal
    url: "tcp://db.internal:5432"
    conditions:
      - "[CONNECTED] == true"

The gotcha is identical in both tools: container DNS. “Connection refused” from inside a container almost always means the hostname does not resolve there, not that Postgres is down.

TLS certificate expiry alerts

  - name: bitdoze
    url: "https://bitdoze.com"
    conditions:
      - "[STATUS] == 200"
      - "[CERTIFICATE_EXPIRATION] > 336h"   # 14 days

Verify without waiting for a real cert to rot: set the Gatus threshold to something huge like 8760h (a year) against any normal certificate and watch the endpoint go red, then set it back.

Push monitors and dead man’s switches

The use case: a nightly backup behind NAT that cannot accept inbound checks. You want an alert when the job does not report in.

curl "https://status.example.com/api/push/PUSH_TOKEN?status=up&msg=backup+finished"

external-endpoints:
  - name: nightly-backup
    group: internal
    token: "CHANGE_ME_LONG_RANDOM_STRING"   # openssl rand -hex 32
    alerts:
      - type: telegram
        send-on-resolved: true
        failure-threshold: 3

curl -X POST \
  -H "Authorization: Bearer CHANGE_ME_LONG_RANDOM_STRING" \
  "https://status.example.org/api/v1/endpoints/internal_nightly-backup/external?success=true"

Alerting: thresholds, notifications, and maintenance windows

An alert nobody trusts is noise. Both tools let you dampen properly, but they express it differently.

Uptime Kuma ships 90+ notification providers (Telegram, Discord, Gotify, Slack, Pushover, ntfy, SMTP, and on). Per-monitor retries control how many failed checks pass before a notification. Note the v2 behavior change: new monitors default to retries: 0. Set 2-3 on anything flappy or you will hate the bot within a week. The certificate-expiry toggle rides the same notification channel.

Gatus ships about 40 provider types (Slack, PagerDuty, Opsgenie, Teams Workflows, Telegram, Discord, ntfy, Gotify, n8n, GitHub and Gitea issues, custom webhooks with placeholders) and pushes threshold logic into the config: failure-threshold, success-threshold, send-on-resolved, and minimum-reminder-interval for the “still down, hourly nag” case. Those live per endpoint or in default-alert.

Maintenance differs too. Gatus has maintenance windows with timezone and weekdays, plus per-endpoint maintenance-windows for that one service you restart every Sunday. Kuma has per-monitor pause and a maintenance concept you set from the UI.

Alerting test protocol (run this once per tool, then after every alerting change):

docker compose logs in both projects shows alert dispatch attempts. If a test alert does not arrive, the logs are the first place to look.

Self-hosted status pages: one dashboard vs many

This is where the tools stop looking alike. A self-hosted status page is the thing your clients look at during an outage, and the two products solve it differently.

Uptime Kuma supports multiple public status pages, each with its own monitor selection, and each mappable to its own domain. That is the feature that pulls client-facing users toward Kuma. Combine it with per-page branding and you have something you can put in front of a customer.

Gatus renders one dashboard/status page per instance. It supports announcements and incident messages, but if you want “one page showing three regions”, the multi-instance aggregation (“remote instances”) is explicitly experimental with known issues (issue #64). Do not build a client commitment on it yet.

Auth follows the same split. Kuma has user accounts with TOTP 2FA for operators. Gatus has basic auth (bcrypt-hashed, cost 9 recommended) and OIDC, but no 2FA of its own, so the OIDC provider has to carry that.

Storage, backups, and what breaks six months in

Six months in, the differences are operational, not functional. Disk grows and the VPS gets rebuilt after a botched upgrade. A config typo takes a dashboard down at midnight. What matters then: how fast you are back in business, and whether anything is left to rebuild by hand.

Uptime Kuma: SQLite growth, the v1 to v2 migration, and backup discipline

Heartbeat history makes Kuma’s SQLite file grow without bound. Users on r/selfhosted report files of several hundred MB and a sluggish monitor list on old instances. The v2 release aggregates heartbeats into a denser format specifically to address this, but do not take “v2 fixed it” on faith until your own instance has months of data on it.

The v1 to v2 migration exists because of that format change. It is one-way, it rewrites the heartbeat table, and the maintainer’s own figure is about 7 minutes for 20 monitors over 90 days, with a warning that it can take hours on slower hardware. Interrupt it and you restore from backup.

Backing up Kuma is file-level: the data/ directory (mounted at /app/data in the container). v2 removed the old JSON backup/restore path, so a data-dir copy is the only supported method. Keep it in your nightly job alongside the rest of the box, for example with self-hosted backups with Restic and Rclone. An offsite target can be anything S3-shaped; some people go as far as mounting an S3 bucket as a filesystem on a VPS for archive copies.

Restore is stop, copy, start. The failure mode that hurts: a corrupted SQLite file with no backup means clicking every monitor back into existence, because there is no declarative export to reload.

Gatus: the memory-storage footgun and the GitOps restore story

With the default memory storage, a routine docker compose restart silently erases your uptime history and alert state. That is worth stating plainly because it bites people. Set storage.type: sqlite (or postgres) on day one and mount a volume at /data.

Once that is done, Gatus has the best restore story in this category. The config is in git, so a VPS rebuild is git clone and docker compose up -d. History is a sqlite file you can take or leave (a pg_dump if you chose Postgres). Your monitoring config backup is literally git push.

One tuning knob matters at scale: concurrency defaults to 3 simultaneous endpoint evaluations (a deliberate semaphore so response-time measurements stay accurate). With many endpoints and the default 10-second timeout, slow checks serialize and skew intervals. Raise concurrency deliberately, lengthen timeouts on the slow endpoints, or split heavy checks onto a second instance. concurrency: 0 disables the limit (it replaces the deprecated disable-monitoring-lock).

Resource usage on a small VPS

Neither tool needs a database container at solo scale, and neither justifies a bigger VPS. Skip Postgres for Gatus unless you want replicas or very large history; skip an external database for Kuma until SQLite genuinely hurts.

Order-of-magnitude RAM figures from third-party writeups: Gatus (a Go binary) around 20-50 MB idle, Kuma (Node.js) around 100-256 MB. Treat those as ballpark, not measurements. Run your own:

docker stats --no-stream

That prints actual usage for whatever is on this box. Do it before and after adding a few dozen endpoints so you are not arguing with a blog post when the monitor is the thing on the table. If the whole VPS feels slow, benchmark your VPS with YABS first and separate disk/network problems from monitor problems.

Sizing: 1 vCPU / 1 GB RAM runs either tool comfortably under 100 endpoints. What grows is disk, and only for heartbeat history. After the 2026 VPS price increases, this is still a rounding error next to the VPS bill itself. A Hetzner Cloud CX-class VPS is the usual pick for this kind of always-on box.

Hardening nod: set mem_limit (compose v2 syntax, or deploy.resources under Swarm) on both containers so a runaway heartbeat table or a stuck probe cannot eat the box, and keep the images pinned (:2, :stable) so upgrades happen when you decide, not when a tag moves.

Verdict: which self-hosted uptime monitoring tool should you run?

For a solo operator with a handful of side projects, either tool works. Pick by workflow, because that is what you will maintain at month six.

Decision flowchart for choosing between Uptime Kuma and Gatus

Choose Gatus if:

Choose Uptime Kuma if:

And yes, running both is legitimate. Gatus for internal and deep checks (ports, JSON contracts, cert expiry, push heartbeats from cron), Kuma for the public status page and the pretty heartbeats. Two single-container tools on one box is still less moving parts than most “all-in-one” observability stacks.

On the “91k stars means Kuma wins” objection: adoption counts the click-ops majority. It does not know whether your infrastructure lives in git. If it does, the YAML tool is the one you will still be happy with when the dashboard is not open.

Total cost of either path: under 300 MB RAM combined, a slice of a $5 VPS, and the 20 minutes to install plus the backup routine you were going to set up anyway.

When neither fits: Prometheus Blackbox Exporter

If you already run Prometheus and Grafana and you want probing to feed dashboards and Alertmanager rules rather than a dedicated status page, the Prometheus Blackbox Exporter is the right-shaped tool. You get probed targets as scrape metrics, and you assemble alerting and status display yourself. That assembly is exactly the work Kuma and Gatus do for you, so pick the exporter only when you are already living in that ecosystem.

For everyone else, the two tools in this article are simpler to install and restore, and they ship a status page without a PromQL detour.

Uptime Kuma vs Gatus FAQ