Gatus

Last reviewed Aug 26, 2026 · 909 words

With Gatus, adding a monitor is a 4-line commit. That single fact decides whether it is for you. If you would rather click through a form and see a pretty graph, Uptime Kuma is the better product and the Gatus vs Uptime Kuma page explains the split. If your homelab is a git repository and you already treat the compose files as the source of truth, Gatus is the best uptime monitor available, in Go, Apache-2.0, 11,900 stars, running in 64 MB and reloading itself when the file changes.

One file is the entire product

There is no database by default, no UI editing, no setup wizard. config.yaml is the product:

endpoints:
  - name: Nextcloud
    group: apps
    url: https://cloud.example.com/status.php
    interval: 60s
    conditions:
      - "[STATUS] == 200"
      - "[RESPONSE_TIME] < 800"
      - "[BODY].maintenance == false"
      - "[CERTIFICATE_EXPIRATION] > 168h"

  - name: Router DNS
    group: infra
    url: "192.168.1.1"
    dns:
      query-name: example.com
      query-type: A
    conditions:
      - "[DNS_RCODE] == NOERROR"

  - name: Postgres port
    group: infra
    url: "tcp://db.lan:5432"
    interval: 30s
    conditions:
      - "[CONNECTED] == true"

The condition language is where Gatus outgrows a ping tool. [STATUS], [RESPONSE_TIME] in milliseconds, [BODY] with a JSON path, [CERTIFICATE_EXPIRATION] and [DOMAIN_EXPIRATION] in durations, [IP], [CONNECTED] and [DNS_RCODE] cover most of what a service can tell you, and helpers like len(), has() and pat() handle the rest. A check that fails when your certificate has under 7 days left, or when an API's health JSON says a dependency is down, is one line rather than a plugin. icmp://, ssh://, starttls:// and WebSocket targets are supported alongside HTTP, DNS and TCP.

Two smaller blocks round out an endpoint. method, headers and body turn a check into a POST against an API that needs authentication, so a GraphQL health query or a login endpoint gets tested for real rather than for a 200 on the front page. A per-endpoint client: block sets timeout, insecure: true for the self-signed certificate on the NAS, and ignore-redirect: true when a 301 is the healthy answer. Gatus watches the file and reloads on save, so a typo shows up in the log within seconds rather than after the next restart, and the container reads GATUS_CONFIG_PATH if you want the file somewhere other than /config/config.yaml.

Alerts with thresholds, so the phone stays quiet

alerting:
  ntfy:
    url: https://ntfy.example.com
    topic: homelab
    default-alert:
      failure-threshold: 3
      success-threshold: 2
      send-on-resolved: true

endpoints:
  - name: Nextcloud
    url: https://cloud.example.com/status.php
    conditions:
      - "[STATUS] == 200"
    alerts:
      - type: ntfy

Three consecutive failures at a 60-second interval means a 3-minute blip does not page you, and send-on-resolved closes the loop. ntfy is the natural partner for a homelab, but the provider list is long: Slack, Discord, Telegram, email, Matrix, Gotify, Pushover, PagerDuty, Opsgenie, Teams, and a custom webhook for everything else. Per-endpoint overrides let a critical service alert on 1 failure while a hobby project waits for 10.

Deploy in 8 lines, decide on storage in 3

services:
  gatus:
    image: twinproduction/gatus:latest
    ports:
      - "8080:8080"
    volumes:
      - ./config:/config
      - ./data:/data
    restart: unless-stopped

The default storage is memory, which means the history graph resets on every restart. Adding a storage: block with type: sqlite and path: /data/data.db keeps 30 days of results in a file worth nothing to back up, and type: postgres is there for the 1% who need it. A security: block with basic auth or OIDC protects the page, metrics: true exposes a /metrics endpoint that Prometheus can scrape, and the single-binary release does all of the same on a Pi Zero with no container runtime.

The dashboard is the status page

Gatus draws one page: groups of endpoints, a green-and-red history bar per endpoint, response-time chart on click, and a badge endpoint per check for READMEs. That page is also your public status page if you expose it, with a ui: block for the title and logo and a maintenance: window that suppresses alerts on Sunday nights. The visualisations stop there, and that is the honest limit: no per-region checks, no incident timeline written in prose, no user accounts. For a homelab and most small teams that is enough, and the comparison of dedicated status-page tools is in self-hosted status pages.

Run it somewhere the failures aren't

A monitor on the server it monitors reports nothing when that server dies. Gatus's 64 MB footprint makes the fix cheap: run it on the second box, the old Pi, or the $4 VPS, and point one external free check at the Gatus page itself so you learn when the monitor goes down. Commit config.yaml next to your compose files, let the container watch the file, and the monitor evolves with the stack instead of drifting from it.

What I'd do

Gatus on a different machine from the services, SQLite storage, ntfy alerts with a 3-failure threshold, and a certificate-expiry condition on every HTTPS endpoint, because expired certificates are the outage self-hosters actually have. Keep Uptime Kuma if a family member needs to add checks through a browser; otherwise this file in git is the monitoring system, and it is the one part of my stack I have never had to think about twice.