Gatus status pages: public observability versus authenticated API control
Gatus monitors endpoints, exposes status pages, and offers an API for managing status pages and endpoint configuration. A status page may be intended for public viewing. The management API is a different surface. The security question is not whether a Gatus page is public. It is which data and actions the public page can expose and whether control routes are protected.
The ZoomEye count-only measurements on November 6, 2026 used sub_type=all, page 1, and page size 1. app="Gatus" returned 0, title="Gatus" returned 1,066, and http.body="Gatus" returned 10,387. The body count is much larger than the title count, so it should be treated as a broad lead rather than a deployment census.
Public status does not mean public administration
A status page can reveal service names, endpoint URLs, response times, certificate details, and incident state. Some organizations want that information public. Others consider it a map of internal dependencies. Decide the intended audience and configure the page and its data fields accordingly.
Gatus documentation describes a security configuration block with Basic authentication and OIDC options, and an API that uses user API keys and status-page tokens. The review should verify the actual API routes and token scopes. A public status page token should not be accepted for administrative changes.
Token and API review
Inventory user API keys and status-page tokens separately. Record owner, purpose, creation date, last use, and revocation path. Test that a status-page token can read only the intended status page and cannot manage endpoints or other pages. Test that an API key has the minimum role required for its automation.
If OIDC is enabled, verify issuer, client, redirect URI, claim mapping, and session policy. A second authentication layer in front of Gatus can be useful, but it does not replace application-level API validation. Proxies may pass headers that the application trusts, so the trust boundary needs an explicit configuration and test.
Data minimization on status pages
Review endpoint names, descriptions, URLs, response snippets, certificate metadata, and error messages. A failing check can reveal internal DNS names or service behavior. The status page should expose only the data needed for its audience. Do not put secrets in endpoint labels or descriptions, even if the page is "only internal."
Availability data can also disclose business operations. A public page that lists every internal service may help an attacker choose targets. Use grouping, generic labels, or restricted pages where the operational value does not require full detail.
A safe evaluation workflow
Start with the organization's known Gatus hostnames. Confirm the status page audience and visible data. Then review configuration and API access in an authorized environment. Do not attempt to create, edit, or delete a status page on an unknown host. Do not use guessed tokens or test paths that could change monitoring state.
Check the network exposure of the UI and API, TLS configuration, authentication mode, external monitoring access, and backup process. Verify that an alerting outage does not expose a secret through error pages. Review how secrets for monitored endpoints are stored and whether they appear in logs.
Interpret the counts
The zero app count, 1,066 title matches, and 10,387 body matches describe this query scope. They do not prove that all matches are Gatus or that unauthenticated administration is available. The body field is especially likely to match documentation, examples, and status-page templates.
The useful output is a boundary map: public status page, authenticated read API, administrative API, configuration data, and endpoint credentials. ZoomEye can help find pages that mention the product. The organization still has to decide what the public page reveals and prove that control routes require the right token or user role.
Top comments (0)