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 6 steps
Order a ServOrbit VPS
Any plan from 512 MB RAM is sufficient — Gatus idles under 80 MB RAM. For reliable monitoring, place Gatus on a separate VPS from the application it monitors: if the application VPS goes down, the monitoring VPS keeps sending alerts.
Deploy from the Marketplace in one click
ServOrbit dashboard → Marketplace → Monitoring → Gatus → Deploy. An init container writes a sample
config.yaml, then Gatus starts. The status page is accessible athttp://your-vps-ip:8080within seconds.Edit the configuration file
SSH into your VPS and edit
/opt/stacks/gatus/config/config.yaml. Replace the sample endpoint with your real services. A minimal HTTP endpoint looks like:endpoints: - name: "My API" url: "https://api.your-domain.com/health" interval: 1m conditions: - "[STATUS] == 200" - "[RESPONSE_TIME] < 1000"Restart with
cd /opt/stacks/gatus && docker compose restart gatus— new endpoints appear on the status page within seconds.Configure alerts
Add an
alerting:block to your config. Example with ntfy (another Marketplace app):alerting: ntfy: url: "http://your-ntfy-vps:8080" topic: "gatus-alerts" priority: 3 failure-threshold: 2 success-threshold: 3 endpoints: - name: "My API" url: "https://api.example.com/health" interval: 1m alerts: - type: ntfy conditions: - "[STATUS] == 200"Gatus only alerts after 2 consecutive failures (avoids false positives) and sends a recovery alert after 3 consecutive successes.
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.
