Skip to main content

comparing self-hosted

Uptime Kuma vs Gatus: clicks or YAML?

The two most-loved self-hosted monitors answer one question differently: should monitoring be clicked together in a dashboard, or declared in a file and reviewed in a pull request? Everything else follows from that split.

The table below is the whole comparison, unedited. Read it first if you like, it is the same one we would send you.

Start free skip to the table

AGPL-3.0 · one binary · free tier · no card required

~/monitoring

cat gatus.yaml

  1. endpoints:
  2. - name: api
  3. url: "https://api.acme.dev/health"
  4. interval: 60s
  5. conditions:
  6. - "[STATUS] == 200"
  7. - "[RESPONSE_TIME] < 300"
  8. # redeploy the config to apply

YAML ONLYgatus has no editing UI, so every change is a redeploy

cat uptimepage.tf

  1. resource "uptimepage_target" "api" {
  2. name = "api"
  3. interval = 60
  4. check = {
  5. type = "http"
  6. http = { url = "https://api.acme.dev/health" }
  7. }
  8. }

CONFIG AS CODEthe same monitor, declared, or clicked together in the UI

history | tail -1

  1. curl -X POST https://app.uptimepage.dev/api/v1/targets \
  2. -H "Authorization: Bearer $UPTIMEPAGE_TOKEN" \
  3. -d '{"name":"api","interval":60,
  4. "check":{"type":"http",
  5. "http":{"url":"https://api.acme.dev/health"}}}'

201 CREATEDmonitor live, and its first check runs straight away

how the Terraform provider declares one →

pick uptime kuma if

It is your homelab, you want the widest check list and one-second intervals, and one shared login is fine.

pick gatus if

Every check belongs in Git, the dashboard is for you and your team, and nobody outside needs to see it.

pick uptimepage if

Customers need a status page they can subscribe to, teammates need their own accounts, and you still want the config in Git.

Start free →

The facts, side by side

  Uptime KumaGatusUptimepage
license MITApache-2.0AGPL-3.0
configuration UI onlyYAML only, read-only UIUI + Terraform + REST + MCP
run it yourself one container (Node)tiny static binaryone binary + compose
hosted option nogatus.io, paidyes, free tier
check types 31 incl. DBs · MQTT · browser11 protocols incl. gRPC · SSH · WebSocketHTTP · TCP · DNS · TLS · domain · ping · heartbeat · flow
fastest interval 1sno documented floor, default 60s60s free · 30s Pro · 10s self-hosted
status page yes, custom domainsdashboard doubles as pagebranded, own subdomain
page subscribers RSS onlynoneemail · webhook
incidents posted by handnoneauto-opened from checks
teams & roles single loginone basic-auth or OIDC gateorgs + roles
alert channels 94 services41 providersSlack · Telegram · PagerDuty · SMS + more
community (GitHub stars) ~89k~11.4kyoung

Kuma counts include the Apprise meta-provider and types implemented outside its monitor-types module; Gatus provider count from its README.

Star counts rounded from GitHub, July 2026.

Verified July 2026 against both repositories. Refresh when a project releases a new version.

Start free

The split that decides it

Uptime Kuma is a dashboard you click: add a monitor, pick a type, wire a notification, all stored in its database. Gatus has no editing UI: every endpoint is YAML in version control, the web UI is read-only, and a change means a config redeploy. Neither is wrong. One fits a homelab and a person who thinks in browsers; the other fits an engineer who thinks in Git and wants monitoring reviewed like code.

What each does well

Kuma wins on reach: 31 monitor types including databases, MQTT, SNMP and a real browser check, 94 notification services, one-second intervals since the 2.x line, and the biggest community in the category. Gatus wins on discipline: eleven endpoint protocols including gRPC, SSH, WebSocket and UDP, a condition language that asserts on status, response time, JSON body paths, certificate expiry and domain expiry, and a tiny static Go binary that can even run without a database.

What neither gives you

A customer-facing status page with subscribers, and a team. Kuma's status pages are real but nobody can subscribe to them, and the whole app is one shared login. Gatus's dashboard doubles as its status page: fine for an internal dashboard, not something you show customers, and its access control is one basic-auth or OIDC gate. Both check from wherever you run them, unless you set up more instances yourself or use Kuma's Globalping monitor type.

Where Uptimepage fits

If the YAML-versus-clicks debate ends with 'actually we need customers to see a status page and teammates to have accounts', that is the gap Uptimepage fills. Checks over HTTP, TCP, DNS, TLS, domain, ping, heartbeat and flow, configured in the UI or declared with the Terraform provider and REST API, organizations with roles, multi-region probes you can run yourself, and a branded status page with email and webhook subscribers where incidents open automatically. One binary, hosted free or AGPL self-hosted.

  1. 01Sign in with GitHub or Google. No card, no sales call.
  2. 02Paste a URL. The first check runs before you have finished reading this.
  3. 03Publish the status page, or export it to Terraform and keep it in Git.
Start free what the page looks like
acme cloud status.acme.dev subscribe

all systems operational checked 12s ago

api99.98%

p95 142ms · one incident in 45 days

dashboard99.91%

p95 318ms · two degraded days

webhooks99.99%

p95 88ms · no incidents

RESOLVED14 min

Elevated latency on the dashboard API

14:22 resolved, latency back under 300ms

14:08 opened automatically by the dashboard check

up degraded down 45 days · email & webhook subscribers

An example page. The monitors, the percentages and the incident are made up.

FAQ

Is Gatus better than Uptime Kuma?
Only for a team that wants monitoring in version control. Gatus declares every endpoint in YAML and asserts on status, response time, JSON body paths and certificate expiry, which reviews like code. Uptime Kuma covers far more monitor types and notification services and needs no config file at all. Neither one wins on merit; they answer different questions.
Should I pick Uptime Kuma or Gatus?
Pick by workflow. If you want to click monitors together in a dashboard, Kuma. If you want every check declared in YAML, reviewed in a pull request and deployed like code, Gatus. Feature lists matter less than that split.
Can Gatus replace a status page?
For an internal ops wall, yes: its dashboard shows health, badges and announcements. For customers, no: there are no subscribers, no incident timeline and no branding beyond what you build around it.
Which is lighter to run?
Gatus. It is a small static Go binary that can even run without a database. Kuma is a Node.js app in one container, still light, just not that light.
What if I need teams or an API?
Neither has real multi-user support or a management API. That is the gap tools like Uptimepage and OpenStatus fill: organizations with roles, a REST API and a Terraform provider on top of the checks.

Links

Uptimepage vs Uptime KumaThe self-hosted field, comparedOpenStatus vs Uptime KumaOpen-source, self-hosted uptime tools

Start in under 5 minutes.

Start free

features · pricing · notes