Uptime Kuma vs Gatus
Uptime Kuma and Gatus compared for self-hosted uptime monitoring and status pages in 2026: UI-driven setup vs YAML config-as-code, monitor types, health-check conditions, alerting, storage, APIs, Prometheus metrics and resource needs.
Quick Answer
Uptime Kuma is the better default if you want to click monitors together in a polished web UI: 2.x supports dozens of monitor types (HTTP, keyword, JSON query, TCP, ping, DNS, push, Docker, databases, MQTT, gRPC, SNMP, real-browser and more), 90+ notification services and multiple status pages on custom domains. Gatus is the better fit when monitoring should live in Git: every endpoint is defined in YAML with conditions on status, body (JSONPath), response time, IP, certificate and domain expiry, it ships as a small Go binary with memory, SQLite or PostgreSQL storage, and it reloads config on the fly.
Last updated October 23, 2026. Covers Uptime Kuma 2.5.7 (23 Oct 2026) and Gatus v5.37.0 (24 Sep 2026), with monitor types, storage options and API status from their READMEs, wikis and release notes in October 2026.
| Feature | Uptime Kuma | Gatus |
|---|---|---|
| Price | Free | Free (managed option at Gatus.io) |
| Licence | MIT | Apache-2.0 |
| Stack | Node.js app (Docker image or Node.js 20.4+ with pm2) | Single Go binary / container image |
| Configuration | Web UI; stored in the database | YAML file, hot-reloaded |
| Monitor Types | HTTP(s), keyword, JSON query, TCP, ping, DNS, push, WebSocket, Docker, databases, MQTT, gRPC, SNMP, SMTP, NTP, real browser and more | HTTP, ICMP, TCP, UDP, SCTP, DNS, SSH, gRPC, WebSocket, TLS, STARTTLS, domain expiry, external (push) endpoints |
| Health-Check Logic | Per monitor type: status, keyword, JSON query, DNS record conditions | Condition expressions on status, body (JSONPath), response time, IP, certificate and domain expiry, DNS rcode |
| Alerting Integrations | 90+ notification services | About 40 providers (Slack, Discord, PagerDuty, Opsgenie, Teams Workflows, ntfy, Matrix, email and more) plus custom alerts |
| Status Pages | Multiple status pages, custom domains, maintenance windows | One dashboard with groups, announcements and badges |
| Storage | SQLite or MariaDB (MariaDB since 2.0) | Memory (default), SQLite or PostgreSQL |
| API | Push and badge endpoints; management API is internal (Socket.io), unsupported | Read-only REST API (statuses, uptimes, response times) |
| Prometheus Metrics | Yes, /metrics with API keys or basic auth | Yes, /metrics when metrics: true |
| Dashboard Auth | Built-in login with 2FA | Basic auth or OIDC |
| Latest Release | 2.5.7 (23 Oct 2026) | v5.37.0 (24 Sep 2026) |
Uptime Kuma
Easy-to-use self-hosted monitoring tool built on Node.js with a reactive web UI, many monitor types, 90+ notification services, multiple status pages and 2FA.
Pros
- Everything is set up in the web UI, so non-developers on the team can add monitors and status pages
- Broad monitor coverage: HTTP(s), keyword, JSON query, TCP, ping, DNS, push, WebSocket, Docker containers, plus database, MQTT, gRPC, SNMP, SMTP, NTP, game-server, Tailscale ping and real-browser monitors in 2.x
- Notifications through Telegram, Discord, Slack, email and 90+ other services
- Multiple public status pages, each mappable to its own domain, with maintenance windows
- Push monitors (/api/push/<token>) for cron jobs and hosts that cannot be reached from outside
- Huge community: about 93k GitHub stars and frequent releases (2.5.7 on 23 Oct 2026)
Cons
- No supported public API for managing monitors: the Socket.io API is internal and may break between versions
- Monitors live in its database, not in files you can review in Git
- The data directory must not be on NFS; backing up the data directory is the only supported backup method in 2.x
- v1 to v2 upgrades rewrite the heartbeat tables and can take hours on large instances
- Non-Docker installs need Node.js 20.4+ and pm2, and BSDs are not supported
Best For
Homelabs, small teams and agencies that want a friendly UI, lots of monitor types and public status pages without writing config files.
Gatus
Developer-oriented health dashboard written in Go that checks endpoints over HTTP, ICMP, TCP, UDP, DNS, SSH, gRPC and more, evaluates the results against conditions defined in YAML and sends alerts to 40+ providers.
Pros
- Configuration as code: endpoints, alerts, maintenance windows and auth live in a YAML file you can review in pull requests, and changes are reloaded on the fly
- Expressive conditions on [STATUS], [BODY] with JSONPath, [RESPONSE_TIME], [IP], [CONNECTED], [CERTIFICATE_EXPIRATION], [DOMAIN_EXPIRATION] and [DNS_RCODE], with len, has, pat and any functions
- Small Go binary and container image, with official Docker, Helm chart and Terraform deployment docs
- External endpoints let private agents push results to a public Gatus with a bearer token
- Read-only JSON API, uptime and response-time badges, and Prometheus metrics when metrics: true
- OIDC or basic auth for the dashboard; Apache-2.0 licence
Cons
- No point-and-click editor: every change means editing YAML
- Default storage is in memory, so history is lost on restart unless you configure SQLite or PostgreSQL
- Only three endpoints are evaluated concurrently by default, so slow checks can delay others until you raise concurrency
- Fewer notification integrations than Uptime Kuma (about 40 providers plus custom webhooks)
- Remote instances and Suites are marked experimental/alpha
Best For
Developers and platform teams who keep infrastructure in Git, run Kubernetes, or need checks that assert on response bodies, certificates and domain expiry.
Click-ops vs config-as-code
This is the real decision. Uptime Kuma is built around its web UI: you add a monitor, pick a type, set an interval and attach notifications, and it is stored in Uptime Kuma's database. That makes it approachable for anyone on the team, but it also means your monitoring setup is not in Git. Uptime Kuma's wiki documents its Socket.io API as internal, primarily for the app's own use, not officially supported for third-party integrations and liable to break between versions. The supported HTTP endpoints are push monitors, badges, Prometheus metrics and public status-page data. Gatus takes the opposite approach. You mount a YAML file (or a directory of them) and define endpoints with a URL, interval, conditions and alerts. Gatus reloads the configuration when the file changes, and by default exits if the new file is invalid unless you set skip-invalid-config-update. Environment variables can be used inside the config, so secrets stay out of the file. Monitoring changes become pull requests, which is why Gatus is popular in GitOps and Kubernetes setups; its README says the author runs it in his own cluster. If you manage everything else with Terraform, Helm or Ansible, Gatus fits that workflow. If the person adding a monitor at 2am is not going to open a YAML file, Uptime Kuma fits better.
What each one can check
Uptime Kuma's README lists HTTP(s), TCP, HTTP(s) keyword, HTTP(s) JSON query, WebSocket, ping, DNS record, push, Steam game server and Docker container monitors, with 20-second intervals. The 2.x source adds dedicated monitor types for PostgreSQL, MySQL/MariaDB, Microsoft SQL Server, MongoDB, Oracle, Redis, RabbitMQ, MQTT, gRPC, SNMP, SMTP, NTP (new in 2.5.0), SIP OPTIONS, system services, Globalping, Tailscale ping, other game servers and a real-browser monitor that loads the page in Chromium. Version 2.5.0 also removed the old 24-day cap on intervals. Gatus covers fewer protocols but evaluates them more deeply. Its FAQ documents HTTP, TCP, UDP, SCTP, WebSocket, gRPC, ICMP, DNS, SSH, STARTTLS, TLS and domain-expiration checks, and v5.37.0 added TXT queries for DNS. Every check passes or fails on a list of conditions: [STATUS] == 200, [BODY].status == UP using JSONPath, [RESPONSE_TIME] < 300, [CERTIFICATE_EXPIRATION] > 48h, [DOMAIN_EXPIRATION] > 720h, [DNS_RCODE] == NOERROR, with len, has, pat and any helpers. That makes Gatus usable for lightweight acceptance tests, which its README calls out, and the alpha Suites feature chains endpoints with shared context. For checks behind a firewall, both have a push model: Uptime Kuma's push monitors take a GET to /api/push/<token>, and Gatus external endpoints accept results from your own agents using a bearer token.
Alerting, status pages and integrations
Uptime Kuma lists notifications via Telegram, Discord, Gotify, Slack, Pushover, SMTP email and more than 90 other services, and each release tends to add a few more (2.5.0 added Plivo SMS and voice among others). Its status pages are a strong point: you can run several, map each to its own domain through a reverse proxy, and schedule maintenance. Note that status pages cache results and refresh every five minutes, so they are less live than the dashboard. Gatus documents about 40 alerting providers in its README, including Slack, Discord, PagerDuty, Opsgenie, Teams Workflows, Telegram, ntfy, Matrix, Mattermost, email, AWS SES, Datadog, Incident.io, Zulip and n8n, plus GitHub, GitLab and Gitea issue creation and a custom HTTP alert for anything else. Alerts have failure and success thresholds and can be set as defaults per provider. Maintenance windows are defined in config by start time, duration, timezone and weekdays. Gatus gives you one dashboard with endpoint groups, announcements, uptime and response-time badges, and a read-only JSON API (/api/v1/endpoints/statuses). Both expose Prometheus metrics: Uptime Kuma at /metrics behind API keys or basic auth, Gatus at /metrics once metrics is set to true. If you need a polished public status page for customers, Uptime Kuma has more to offer.
Running it: storage, resources and upgrades
Uptime Kuma runs as a Docker container (louislam/uptime-kuma:2) on port 3001, or from source on Node.js 20.4+ with pm2 on Linux and Windows; BSDs are not supported. Data lives in /app/data, which must be on local storage because NFS is not supported. Version 2.0 added MariaDB support alongside SQLite, removed the old JSON backup and restore, and the v1 to v2 migration aggregates the heartbeat table, which the maintainer's own guide says took about 7 minutes for 20 monitors with 90 days of data and can take hours on bigger instances. Back up the data directory before every upgrade. Gatus is a single Go binary, published on GitHub Container Registry and Docker Hub, with Helm chart and Terraform examples. Storage defaults to memory, so results disappear on restart; set storage.type to sqlite with a path or to postgres with a connection URL for history, and enable caching for large dashboards. Gatus limits concurrent evaluations to three by default to keep response-time measurements accurate; raise concurrency if many slow endpoints delay each other. Dashboard access can be protected with basic auth or OIDC, and remote instances (experimental) can aggregate several Gatus servers. Both are free. Gatus also points to a managed hosted service at Gatus.io if you do not want to run it yourself.
Verdict
Choose Uptime Kuma if the people adding monitors want a web UI, if you need many monitor types out of the box (databases, Docker containers, MQTT, game servers, real-browser checks), more than 90 notification services, or several public status pages on their own domains. Choose Gatus if your monitoring should be reviewed and versioned like the rest of your infrastructure: endpoints and alerts in YAML, conditions that assert on JSON bodies, certificate and domain expiry, Kubernetes-friendly deployment, Prometheus metrics and a read-only API. If you choose Gatus, configure SQLite or PostgreSQL storage from day one, because the default memory store loses history on restart. Both are free and self-hosted, and plenty of teams run both: Gatus for engineering checks in Git, Uptime Kuma for a public-facing status page.