Where should your own monitor run?
A website check sees what is reachable from the machine running Kuma. For example, the site may open on your office network while customers elsewhere see a failure. Put the monitor where its view matches the problem you want to detect. If it shares the same host as the site, one outage may take down both.
A push check is the opposite direction. Your scheduled job sends a short signal when it finishes. Put the signal after the real work, so an early “started” signal cannot stand in for a finished result.
What do customers see on the status page?
Uptime Kuma’s documentation describes its status page as public-facing and says it caches and refreshes the display on a five-minute cycle. Choose public labels and only the monitors you want visitors to see. Keep the administration dashboard and credentials restricted.
What are you responsible for when moving or upgrading?
You provide the host, its updates and its storage. In the documented local setup, keep a backup of Kuma’s persistent data directory. The version 2 migration guide says to stop Kuma before backing up that directory and says the former JSON backup feature was removed.
If your setup has a separate database, plan its backup separately. Restore in a private test copy with notifications disabled or routed only to test recipients before relying on the recovery procedure.
How can you tell if the monitor will be there during an outage?
Draw the app, monitoring machine and alert destination on paper. Use fictional labels only.
- Draw a site-only failureMark whether the monitor can still record the failure and who can see it.
- Draw a shared-host failureCross out the machine running both services. The alert and the status page may both be unavailable. Label the monitoring gap before choosing where to host the real check.