Gatus

What is Gatus?

Gatus defines health checks as YAML: a URL, an expected status code and optional conditions on the response body. It serves a status page, tracks response times and alerts when something stops behaving as declared.

Best for

Service health checks you can keep in version control

Why choose Gatus

Gatus turns health checking into a file you review. Each endpoint is a YAML entry with a URL, the conditions that define healthy — status code, response time, a string in the body — and the alert channel to use when it fails. Putting checks in version control means a change to what 'healthy' means shows up in a diff instead of being buried in a web UI somebody configured two years ago. It serves a status page as well as running the checks, so external and internal views can share one source of truth, and it stores response times so slow degradation is visible before something fails outright. For a homelab or a small service, it replaces a paid uptime service with a file.

Replaces

• UptimeRobot
• Pingdom
• Statuspage

Key features

• HTTP, TCP, ICMP and DNS checks
• Conditions on status, body and response time
• Built-in status page
• Many alerting providers

What to watch out for

Gatus runs from wherever you deploy it, so checks are only as meaningful as that vantage point — a checker inside the same network cannot see a DNS or routing problem the outside world experiences. It is a checker, not a full monitoring system: no metrics collection, no dashboards of resource usage, no log correlation. The status page is public by default unless you configure otherwise, which can expose internal service names. Alert recovery, grouping and escalation are simpler than what Alertmanager offers, so teams with real on-call rotations often outgrow it. High-frequency checks against many endpoints also add up if you are hitting third parties.

How to deploy

• Single binary or Docker
• Mount a config.yaml with endpoints
• Expose the status page behind a proxy

Getting started

Define a small number of checks that map to user-visible capabilities rather than individual ports, because port checks fire on healthy machines and hide real outages. Set explicit conditions — expected status code, a response time ceiling and a body match — rather than relying on 'the request did not error'. Configure at least two notification channels of different kinds so a single provider outage does not mask an incident. Choose the check interval with the third parties in mind, and keep the status page private unless you intend it to be public. Keep the config in a repository from the first commit, since that is the whole point.

Typical setup

A single container with a persistent volume for its own database and a YAML config committed to a repository. Checks are defined against user-visible capabilities rather than every open port, with explicit conditions on status code, response time and body content. Notification channels are configured in pairs so a provider failure does not hide an outage. The status page is deliberately private unless it is meant to be public, and its database is included in backups because losing it loses the response-time history that makes slow degradation visible.

Who should look elsewhere

Do not use Gatus as your entire observability strategy — it tells you up or down and how fast, and nothing about why. Skip it if you need escalation policies, on-call schedules and multi-team routing, which is Alertmanager or a hosted incident tool. And if you run a fleet of machines whose internals you also care about, a metrics system will cover both that and availability, making a separate checker redundant.

Project health

• GitHub stars: 12,217
• Last code push: 2026-09-30
• Open issues: 395
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.