Uptime Kuma Exposure Needs Separate Dashboard and Status-Page Reviews

Uptime Kuma provides monitoring dashboards, public status pages, and metrics access. Those surfaces have different intended audiences. A status page may be designed to be public, while the administrative dashboard and monitoring API need stronger protection. Counting the product without separating these paths can lead to the wrong exposure decision.

The project's API documentation describes Socket.IO communication after authentication for interactive use. It also documents a Prometheus metrics endpoint whose authentication depends on server settings and API-key configuration [1]. The API-keys documentation says that after the first API key is added, basic authentication is permanently disabled for the protected endpoints [2]. An operator should record which method is active, which endpoints it protects, and whether a public status page shares the same hostname or reverse proxy.

On 2026-10-29 at 19:45 UTC, ZoomEye returned 579,925 matches for app="Uptime Kuma" and 74,489 for title="Uptime Kuma". Both queries used sub_type=all, page 1, and pagesize=1; the matched totals came from the SDK response [3]. The application query is preserved in the search link [4]. The application count is much larger in this observation. That does not prove that 579,925 public dashboards exist. Application fingerprints can cover assets with shared components, and a match does not establish the exposed route, authentication setting, or version.

The separate counts are still useful because they expose a large difference. Start with a bounded validation sample and confirm the response and route. Determine whether the observed service is the dashboard, a status page, a metrics endpoint, or an application page that contains the product name. Record the public hostname and path for each surface. A reverse proxy may expose /status publicly while protecting /dashboard and /metrics, or the opposite.

Inventory should include the dashboard endpoint, status-page slugs, monitor groups, API-key state, metrics exposure, notification integrations, and the database location. Review who can create monitors, read check results, change notification credentials, and export data. Status pages can reveal internal service names, hostnames, and maintenance schedules. That may be intentional for customers, but it is still an information disclosure decision.

A negative test should request the dashboard and metrics endpoint without credentials from an external network. Then request a public status page and confirm that only the intended content is visible. Test basic authentication versus API-key behavior on the metrics route. Submit a revoked key and confirm rejection. Review whether the status page leaks administrative links, monitor notes, or internal addresses.

Protect the administrative dashboard with a restricted network or an authenticated proxy. Require MFA at the identity layer where available. Store notification and integration secrets outside public repositories, rotate them when an administrator leaves, and review webhook destinations. Back up the Uptime Kuma data directory and database carefully because it contains monitor configuration and potentially sensitive notification settings.

Monitor login failures, API-key creation and deletion, monitor changes, notification configuration, and exposure changes at the reverse proxy. A public status page is not an incident by itself. The review should establish which data is visible, who approved that visibility, and whether the dashboard and metrics layer remain protected.

ZoomEye gives the team a broad external measurement and a way to compare changes. It cannot distinguish the dashboard from a public status page. The useful conclusion combines the query with route evidence, authentication testing, and a data-exposure decision for each surface.

References

1. Uptime Kuma API documentation
2. Uptime Kuma API keys
3. ZoomEye API and search documentation
4. ZoomEye application query for Uptime Kuma