Why Gatus rather than a classic ping monitor
An HTTP ping tells you your server is responding. Gatus tells you it's responding *correctly*: you define the exact conditions — [STATUS] == 200, [RESPONSE_TIME] < 800, [BODY] contains "ok", [CERTIFICATE_EXPIRATION] > 14d — and Gatus raises an alert the moment a condition is no longer met.
The practical difference: you discover that an API is silently returning 500, that a certificate expires in 10 days, or that a DNS record points to the wrong IP — before your customers do. All driven by a YAML file you version alongside the rest of your infrastructure.
What Gatus monitors — and Uptime Kuma can't
- Rich HTTP conditions: exact status code, response time in ms, body content by regex, JSON field value — in a single endpoint definition.
- TLS certificate expiry:
[CERTIFICATE_EXPIRATION] > 14dtriggers an alert when fewer than 14 days remain before the certificate expires. - TCP, ICMP, DNS, WebSocket: monitor a database (
tcp://db:5432), a network ping (icmp://gateway), a DNS resolution (dns://ns1.example.com) or a WebSocket echo from the same config. - Public status page: one URL to give customers so they can check your service health without emailing you.
- 40+ alert channels: Slack, PagerDuty, OpsGenie, Discord, Teams, ntfy, Pushover, Telegram, email, webhook — with configurable thresholds to avoid flap noise.
Architecture: a single Go container, under 256 MB RAM
Gatus is a Go binary distributed in a distroless image (under 20 MB). A single container, no external runtime dependency: check history is stored in a SQLite database in a Docker volume. On ServOrbit, an alpine:3.20 init container generates a starter config.yaml on first launch — you then edit it over SSH to add your own endpoints.
Idle memory footprint is under 80 MB. A 512 MB VPS is more than sufficient, even if you co-locate Gatus with the application it monitors.
Self-hosting Gatus on a VPS in 5 steps
Logging in for the first time
Gatus has no accounts: the URL takes you straight to the status page, which is public by default. Your real first step is configuration — edit config.yaml to replace the sample endpoint with your own services, then restart it with docker compose restart gatus
Tip: version-control your config.yaml in a private repository
The Gatus config.yaml file is your source of truth for monitoring. Initialize a git repository in /opt/stacks/gatus/, commit your config on every change, and you have a complete history of your monitored endpoints, alert thresholds and their evolution over time — just like your infrastructure code.
