Uptime Kuma vs Gatus

Uptime Kuma — strengths

• Zero config-file knowledge required — all monitors created and edited in a polished web UI
• 90+ notification integrations built in with no plugins needed
• Polished public status pages that can be customised with your own domain and logo
• Docker monitor type checks container health without an HTTP endpoint
• Push monitor mode lets internal services ping Uptime Kuma to confirm they are alive (useful for services behind firewalls)

Uptime Kuma — weaknesses

• No declarative config — all state is in SQLite, not version-controllable
• Response condition checks are limited compared to Gatus
• Single-user, no RBAC

Gatus — strengths

• Entire configuration is YAML — diff it, commit it, review it, roll it back, deploy it with Ansible or a Helm chart
• Rich condition system: check HTTP status, JSONPath values, response time, DNS record content, and TLS certificate expiry in the same monitor block
• First-class Prometheus metrics endpoint for integrating with Grafana dashboards alongside your other observability data
• Extremely lightweight — single Go binary, ~20 MB RAM idle
• Kubernetes-friendly: ConfigMap or env-var driven, easy to deploy as a Deployment with a mounted config file

Gatus — weaknesses

• No web UI — YAML-only configuration
• Smaller notification library
• Status page customisation is more limited

When Uptime Kuma fits

• Non-technical household member managing a homelab who does not want to edit YAML: Uptime Kuma's click-through monitor setup is accessible without any prior knowledge of config-file formats.
• Small SaaS that needs a professional-looking status page at status.example.com for customers: Uptime Kuma's status page editor, custom domain support, and maintenance window announcements handle this without a separate tool.
• Homelab with mixed service types (websites, game servers, Docker containers, TCP services): Uptime Kuma's check-type breadth covers all of these in one UI without needing multiple monitoring tools.

When Gatus fits

• SRE team that manages infra as code and wants health checks in the same git repo as the services: a Gatus config checked in to the infra repo means monitor definitions are reviewed in PRs alongside the services they monitor.
• Platform team that wants to assert specific API response values, not just status codes: Gatus lets you write `body.store[0].status == available` using JSONPath — Uptime Kuma cannot evaluate response body fields structurally.
• Kubernetes cluster already running Prometheus and Grafana: Gatus's /metrics endpoint feeds into an existing Grafana dashboard without additional tooling; it is a natural fit for the existing observability stack.

Uptime Kuma gotchas

• All config lives in the SQLite database — there is no export-to-YAML for version control; if the DB is corrupted, your entire monitor setup must be rebuilt manually
• Keyword checks are basic — you can check that a response body contains a string, but not evaluate a JSON field value, compare against a threshold, or run regex conditions
• Single-user design means there is no concept of read-only viewers; sharing the instance means sharing credentials
• SQLite can become a bottleneck or corruption risk at high check frequencies across hundreds of monitors; consider MariaDB for large setups

Gatus gotchas

• No web UI for creating or editing monitors — you edit YAML and reload; this is a strength for engineers but a barrier for less technical users
• Smaller notification library than Uptime Kuma — if you need an obscure notification channel, check compatibility before committing
• Status pages are clean but less visually polished and customisable than Uptime Kuma's out of the box
• No push-mode monitor type — services behind firewalls that cannot receive inbound connections need a different approach (expose a health endpoint, or use a different tool)

Choose Uptime Kuma when

Pick Uptime Kuma if you want to manage monitors through a friendly web UI, need a polished public status page, and do not require YAML or version control for your monitoring config. It is also the better pick for non-engineers or mixed technical households.

Choose Gatus when

Pick Gatus if you manage infrastructure as code, want rich response-body condition checks, care about Prometheus metrics integration, or run in Kubernetes where a ConfigMap-driven tool fits naturally. It is the better pick for engineers who prefer declarative config over a web UI.

Migration

Both run independently and monitor the same endpoints, so running both briefly in parallel is easy and risk-free. Migrating from Uptime Kuma to Gatus means manually transcribing your monitors from the Uptime Kuma UI into Gatus YAML — there is no automatic export. Migrating the other way means clicking through the Gatus config and creating monitors in the Uptime Kuma UI. Status page history does not transfer in either direction. Start with your highest-priority monitors and expand from there rather than migrating everything at once.

Frequently asked questions

Can Gatus show a public status page?

Yes — Gatus has a built-in status page that shows monitor history and current status. It is clean and functional but less visually polished and customisable than Uptime Kuma's status page editor.

Can Uptime Kuma check a JSON field in an API response?

Only basic keyword presence. It can check that a response body contains a specific string, but it cannot evaluate a JSONPath expression or compare a numeric value against a threshold. Gatus handles this natively with its condition syntax.

Which uses less memory?

Gatus, by a significant margin. The Go binary sits at ~20–50 MB idle. Uptime Kuma's Node.js runtime is closer to 100–150 MB. On a constrained device (Pi Zero, small container allocation), this matters.

Do both support TLS certificate expiry alerts?

Yes. Both check certificate expiry and can alert when a cert is approaching its renewal date. Gatus additionally lets you set a condition like `certificate.expiration > 7d` in the same config block as the HTTP check.

Can I run both?

Yes. They do not conflict. Some setups use Gatus for deep API health checks integrated with Prometheus and Uptime Kuma for the public customer-facing status page — each doing what it does best.

What about Prometheus Blackbox Exporter?

Blackbox Exporter is the Prometheus-native approach to HTTP/ICMP/DNS probing and feeds results into Grafana. It is more complex to configure but better integrated with the Prometheus/Grafana observability stack. Gatus is often easier to start with and covers most of the same use cases with simpler YAML.