# Gatus: Developer-Oriented Health Monitoring with a Status Page

> Gatus is an open-source health monitoring tool written in Go that checks HTTP, ICMP, TCP, and DNS endpoints against configurable conditions and renders a status page. It deploys as a single Docker container with a YAML configuration file, and supports over 25 alerting integrations.

**TwiN/gatus** — Automated developer-oriented status page with alerting and incident support.

- Repository: https://github.com/TwiN/gatus
- Website: https://gatus.io
- Stars: 12,212 · Forks: 844
- Language: Go
- License: Apache-2.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/twin-gatus

## What Gatus Monitors and Who It Targets

Gatus monitors service health by periodically sending requests to configured endpoints and evaluating the responses against a set of conditions. It supports four protocols: HTTP, ICMP (ping), TCP (port checks), and DNS queries. The status page shows the health history of each endpoint and serves as a public or internal status dashboard.

The tool is described as developer-oriented, meaning its configuration is code-like (YAML with condition expressions) and its deployment pattern assumes someone comfortable with Docker or Kubernetes. A developer running a personal project can point Gatus at their API and get alerts to a Discord channel. A team running a production service can deploy it in a Kubernetes cluster (the author states personal use in a Kubernetes cluster in the README) and use it alongside Prometheus metrics. A managed option exists at Gatus.io for teams that prefer not to operate the infrastructure.

## How Gatus Evaluates Conditions

The core mechanism is the condition system. Each endpoint in the YAML configuration file defines a list of conditions that must pass for the check to be considered healthy. Conditions can test the HTTP status code, response time, TLS certificate expiration, DNS resolution results, and response body content.

The README documents placeholders like [STATUS], [RESPONSE_TIME], [BODY], [CERTIFICATE_EXPIRATION], [DNS_RCODE], and [CONNECTED] for TCP. Conditions are written as expressions such as [STATUS] == 200, [RESPONSE_TIME] < 500, or [BODY] == pat(*success*). Functions include len() for response body length and has() for substring checks. The go.mod shows that the github.com/TwiN/jsonpath library provides JSONPath extraction from response bodies, which enables conditions against specific fields in a JSON response.

Threshold-based alerting uses failure and success thresholds per endpoint. An alert triggers after a configured number of consecutive failures (failureThreshold) and resolves after a configured number of consecutive successes (successThreshold). This prevents alerting on transient failures.

## Installing Gatus with Docker

The fastest start is a Docker run with the stable tag:

```console
docker run -p 8080:8080 --name gatus ghcr.io/twin/gatus:stable
```

A Docker Hub image is also available:

```console
docker run -p 8080:8080 --name gatus twinproduction/gatus:stable
```

The Dockerfile builds a minimal binary on golang:alpine and copies only the binary and config.yaml into a scratch container with no OS layer. The GATUS_CONFIG_PATH environment variable controls where Gatus looks for its configuration file; the default is the config/ directory. The PORT environment variable defaults to 8080. GATUS_LOG_LEVEL controls log verbosity and defaults to INFO.

For building from source, the Makefile provides:

```bash
go build -v -o gatus .
```

A Helm chart is referenced in the README for Kubernetes deployments, as is a Terraform module. The Makefile also includes docker-build and docker-run targets for local container builds.

## Alerting: Over 25 Supported Channels

Gatus supports alerting through a large set of integrations. The README documents individual configuration sections for: AWS SES, ClickUp, Datadog, Discord, Email (SMTP), Gitea, GitHub, GitLab, Google Chat, Gotify, HomeAssistant, IFTTT, Ilert, Incident.io, Line, Matrix, Mattermost, Messagebird, n8n, New Relic, Ntfy, Opsgenie, PagerDuty, Plivo, Pushover, Rocket.Chat, SendGrid, Signal, SIGNL4, Slack, Splunk, Squadcast, Teams Workflow, Telegram, Twilio, Vonage, Webex, Zapier, and Zulip. Custom alerts using webhooks are also documented.

A default alert can be set once and applied to all endpoints that do not define their own alerting configuration. The go.mod confirms these integrations are implemented directly in the Go codebase rather than through external plugins; the alerting/ directory in the repository root contains the integration implementations.

The README notes that the Teams alert integration (not the Teams Workflow variant) is deprecated. Teams Workflow is the current supported path for Microsoft Teams alerting.

## Advanced Configuration: Maintenance Windows, Security, and Metrics

Maintenance windows allow silencing alerts during planned downtime. The configuration supports time-based schedules so that a nightly deployment window does not trigger pages.

Security options include basic authentication and OIDC. The go.mod shows github.com/coreos/go-oidc/v3 as a direct dependency, confirming the OIDC support is native rather than proxied.

Gatus exposes Prometheus metrics through a /metrics endpoint, enabled through the metrics configuration block. The go.mod includes github.com/prometheus/client_golang as a dependency. Custom labels can be applied to the metrics, and the README documents this under a Custom Labels subsection.

The configuration supports environment variable substitution, which allows secrets (API keys, webhook URLs) to be injected at runtime rather than stored in the YAML file. The FAQ section in the README also documents configuration reloading on the fly, endpoint groups for organizing the status page, and a startup delay setting for avoiding false alerts when dependent services have not yet started.

## Where Gatus Is Not the Right Tool

Gatus evaluates conditions from outside the service. It cannot test internal application logic, database query performance, or business-level health metrics. An endpoint can return HTTP 200 while the application is functioning incorrectly; Gatus will mark it as healthy.

The DNS monitoring, TLS expiration checking, and domain expiration monitoring cover the infrastructure layer. Application performance monitoring (APM) at the code level requires a different tool such as an OpenTelemetry instrumented service.

Gatus also does not aggregate logs or provide distributed tracing. It is a health check and status page tool, not a full observability stack. Grafana and Prometheus together cover the metrics and visualization side; Gatus's Prometheus integration makes it possible to feed Gatus health data into a Grafana dashboard alongside application metrics, but Gatus does not replace those tools.

## Comparing Gatus to Uptime Kuma

Uptime Kuma is another self-hosted uptime monitoring tool with a status page. Both are open-source and deploy via Docker. Uptime Kuma's configuration is web-based through a graphical interface; Gatus uses a YAML configuration file. This is the primary practical difference.

The YAML approach in Gatus suits teams that manage infrastructure as code, where configuration changes go through version control. Uptime Kuma's UI suits users who prefer configuring monitors through a browser without writing YAML.

Gatus's condition system is more expressive for custom checks. The ability to write conditions against specific JSON body fields, DNS response codes, or TLS expiration days provides more granular health assessment than simple up/down checking. Uptime Kuma supports a broader range of notification channels in some areas but Gatus's list of over 25 integrations covers the most common enterprise and developer tools.

The last push to the Gatus repository was on 2026-09-24, with version v5.37.0 released on the same date.

## Conclusion

Gatus is the right choice for a developer or small team that wants to run a self-hosted status page and receive alerts through their existing notification channels without paying for a SaaS uptime service. The Apache-2.0 license and Docker-based deployment make it straightforward to evaluate. Before deploying, check whether your alerting channels are on the supported list (over 25 are documented in the README), and review the Experimental and ALPHA tags in the configuration documentation since some features are not yet considered stable. A managed cloud option is available at Gatus.io for teams that prefer not to self-host.

## FAQ

### How do I use Gatus?

Create a YAML configuration file defining your endpoints and conditions, then run the Docker container with that file mounted. The status page is available at port 8080 by default. Set the GATUS_CONFIG_PATH environment variable to point to your config file location.

### Is Gatus free?

The self-hosted version is free and open-source under the Apache-2.0 license. A managed cloud option is available at Gatus.io for teams that prefer not to run the infrastructure themselves.

### How does Gatus compare to Uptime Kuma?

Gatus uses a YAML configuration file and a condition expression system that can test JSON body fields, TLS expiration, and DNS response codes. Uptime Kuma configures monitors through a web UI rather than code. Gatus suits infrastructure-as-code workflows; Uptime Kuma suits teams that prefer a graphical configuration interface.

## Sources

- [Official documentation](https://gatus.io)
- [Official README](https://github.com/TwiN/gatus#readme)
- [Project repository](https://github.com/TwiN/gatus)
- [Release notes](https://github.com/TwiN/gatus/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/twin-gatus