Skip to content
Guides

Watch your Uptime Kuma from outside

Uptime Kuma watches everything except itself. If the machine it runs on goes down, loses power or loses its connection, Kuma goes quiet along with it. One check from outside fills that gap, and it fits in a free plan.

By · Published Nov 1, 2026

Drafted with AI assistance, reviewed and published by Jose Franco.

The blind spot

A monitor can only send an alert while it is running and connected. When the host under Uptime Kuma reboots into a broken state, the disk fills, or the house loses its internet connection, Kuma stops checking and stops notifying at the same moment. Nothing arrives, and silence looks exactly like everything being fine.

That is why people run a second, outside monitor whose only job is Kuma. One Hacker News commenter put it plainly: “I only use it to monitor the Uptime Kuma that monitors the rest of my homelab.” The outside check has to live somewhere else, on different hardware and a different network, or it shares Kuma's failure.

If Kuma has a public address

If your Kuma dashboard or a Kuma status page is reachable from the internet (through a reverse proxy or a tunnel), add an HTTP check on that address in RealUptime Monitor. A Kuma status page is the best target, since it needs no login and only renders when Kuma is serving. Free checks run every minute from four regions (US-East, US-West, Europe, and Asia-Pacific), and a failure has to persist before it alerts, so a single dropped packet does not wake you.

To check that Kuma is actually serving, not just that the proxy answers, add a body assertion for text that only appears on a working page, such as your status page title.

If Kuma is only on your network

Most homelab installs have no public address, so nothing outside can reach them. Turn the direction around with a heartbeat: Kuma's host pings RealUptime every minute, and the alert fires when the pings stop. Create a heartbeat monitor with a 60-second interval and a couple of minutes of grace, copy the ping URL, and add one crontab line on the Kuma host:

* * * * * curl -fsS -m 10 http://localhost:3001/ > /dev/null && curl -fsS -m 10 "$PING_URL" > /dev/null

The ping is sent only when Kuma answers on its port (3001 by default; change it if yours differs), so it goes quiet when Kuma has crashed as well as when the host or the connection is gone. Run it from the Docker host if Kuma is in a container, with the published port.

What each one catches

  • Host down, power cut, or connection lost: both. The HTTP check fails; the heartbeat stops arriving.
  • Kuma crashed but the host is up: both, as long as the HTTP check asserts on the page content or the heartbeat is gated on Kuma answering, as above.
  • Kuma is up but its notifications are broken: neither. Send a test notification from Kuma after any change to its notification settings.

Either way it is one monitor of the 10 on the Free plan, with alerts by email, Slack, Discord, Microsoft Teams, Telegram, ntfy, Pushover, webhooks and more, and no card.

Going further

The two most-wanted Uptime Kuma features on GitHub are an API (785 reactions on issue 118) and checks from more than one place (533 on issue 84), both still open. RealUptime has a REST API, a Terraform provider and a CLI on every plan, and reads each check from several regions on the same run. If you want to move some public-facing monitors over, the Uptime Kuma importer takes a 1.x backup or the 2.x /metrics page. The same account includes Status for a hosted status page, Errors for application exceptions, and Outages for the services your homelab depends on.