Uptime Kuma is a lightweight tool for monitoring whether websites, APIs, and other services are reachable and responding as expected. It is quick to deploy, but the deployment location matters. If Uptime Kuma runs on the same infrastructure as the service it monitors, a server or network failure can take both the application and the monitoring system offline. A better setup places the monitor outside the environment it is checking.
What Uptime Kuma Does and What It Does Not Replace
Uptime Kuma is designed to check service availability from an external point of view. It can monitor endpoints on a schedule, record response time and uptime, send notifications when checks fail, and provide a status page. Because it is self-hosted and relatively lightweight, it can be practical for small development and operations teams.
Uptime Kuma is not a replacement for infrastructure monitoring. It does not provide the same server-level visibility into CPU, memory, disk, or long-term capacity metrics. A practical approach is to use a platform such as Zabbix for infrastructure and resource monitoring, while Uptime Kuma checks availability from outside the service and handles related notifications and status communication.
Run Uptime Kuma Outside the System It Monitors
The location of the monitoring instance is important. If Uptime Kuma shares the same server, hypervisor, network path, or cloud region as the application, it can be affected by the same failure. When the monitored environment becomes unavailable, the monitoring dashboard and notification path may become unavailable at the same time.
For public services, a small Uptime Kuma instance at another provider or in another region is usually sufficient. Internal services that cannot be reached from the public internet may need a second monitoring instance inside the network. In that case, keep an external monitor for the services that customers rely on whenever possible.
A monitoring system should remain available when the application it monitors becomes unavailable.
Choose the Uptime Kuma Monitor Type for Each Service
Uptime Kuma supports several monitor types, and the right choice depends on how a service can fail. A basic HTTP check may not detect an application that returns an error page with an HTTP 200 status code, so some services need a keyword, JSON, TCP, DNS, or push check instead.
| Monitor type | Use it for | Notes |
|---|---|---|
| HTTP(s) | Public endpoints where the status code is meaningful | Confirm that the application actually returns an error status on failure before relying on this alone |
| HTTP(s) Keyword | Pages and APIs that can fail while still returning 200 | Match a string that only appears when the page rendered correctly, not a word from the layout |
| HTTP(s) Json Query | Health endpoints that return a status field in JSON | Useful when the endpoint reports degraded dependencies rather than a simple up or down |
| TCP Port | Services without HTTP such as mail, database, or message brokers | Confirms the port accepts connections, which is weaker evidence than a protocol-level check |
| Ping | Basic network reachability | ICMP is often filtered or deprioritised, so treat it as supporting evidence rather than proof |
| DNS | Resolution and record correctness | Catches registrar, propagation, and provider problems that an endpoint check reports only as a generic failure |
| Push | Cron jobs, backups, and scheduled processes | The job calls a URL on success, and the alert fires when the expected heartbeat does not arrive |
Push monitors are useful for scheduled jobs that do not expose an endpoint to check. A backup job, for example, can send a heartbeat after a successful run. If the expected heartbeat does not arrive, Uptime Kuma can report the failure. HTTP monitors can also check TLS certificate expiry and provide advance notification.
Configure Retries and Notifications for Reliable Alerts
A single failed request does not always mean that a service is down. Temporary network errors can produce an isolated failed check, so sending an alert after the first failure can create unnecessary noise. Configure retries and a suitable retry interval so Uptime Kuma confirms repeated failures before treating them as an incident.
- Set the check interval according to how quickly a failure needs to be known. Sixty seconds is a reasonable default, and shorter intervals mainly increase load without improving the response that follows.
- Use retries with a shorter retry interval so a genuine outage is still confirmed within a minute or two while single dropped requests are ignored.
- Configure the resend option so an unresolved incident notifies again periodically, which prevents a single missed message from becoming an unnoticed outage.
- Attach at least two notification channels to critical monitors, because a broken integration or a rate-limited bot token otherwise results in complete silence.
- Schedule maintenance windows before planned work so expected downtime does not page anyone or appear as an incident on the status page.
- Route by importance rather than sending every monitor to the same channel, so the notifications that require immediate action are not buried among informational ones.
Use the Uptime Kuma Status Page for Service Communication
Uptime Kuma can also provide a status page that gives users a clear view of service availability. During an incident, this can reduce repeated requests for updates by showing which services are affected and whether the issue is being investigated or resolved.
The status page should be hosted independently from the infrastructure it reports on. Service names should also use terms that users understand instead of internal hostnames. For example, a customer should see a service such as 'Payment Service' rather than an internal name such as 'api-gateway-02'.
Uptime Kuma Operational and Maintenance Considerations
- The application stores its configuration and history in a data directory, so that directory must be a persistent volume and must be included in backups. Recreating the container without it means rebuilding every monitor by hand.
- Place the interface behind a reverse proxy with TLS and restrict administrative access, then enable two-factor authentication. The instance holds notification tokens and knows the layout of the environment.
- Keep the version current. Updates are straightforward for a single-container deployment, and monitoring software that has not been updated in a year is an unnecessary risk on an internet-facing host.
- Watch the combination of monitor count and check frequency rather than either number alone. Several hundred monitors at short intervals on a minimal instance will produce delayed checks that look like false alarms.
- Review the monitor list quarterly. Decommissioned services that still have monitors create recurring alerts, and services added since the last review are usually the ones nobody is watching.
How to Set Up Uptime Kuma in Practice
- 1List the services that matter to users and the person responsible for each one, before creating any monitor. A check without an owner produces notifications that nobody is accountable for resolving.
- 2Deploy the instance outside the environment it will watch, with persistent storage, TLS, and restricted administrative access from the start rather than as a later hardening step.
- 3Create monitors for the most important user-facing flows first, using keyword or JSON checks where a status code alone would not detect a failure.
- 4Add push monitors for backups and scheduled jobs, since silent failures in these areas are usually discovered at the worst possible moment.
- 5Configure retries, resend behaviour, and at least two notification channels, then verify the alerting path by deliberately failing a test monitor rather than assuming it works.
- 6Publish a status page with service names the audience understands, and agree who updates the incident message during an outage.
What a Good Uptime Kuma Setup Looks Like
A well-configured Uptime Kuma deployment produces notifications that correspond to issues requiring attention. The monitoring instance remains independent from the systems it checks, planned maintenance is handled without unnecessary alerts, and the status page provides a simple source of service information. Over time, uptime data can also support service reviews and operational reporting.
Uptime Kuma is focused on availability rather than root-cause analysis. Its role is to provide a reliable indication that a monitored service has stopped responding or no longer meets the configured check, together with notifications through the channels the team uses.
Key takeaways
- Deploy the monitor outside the infrastructure it watches. A monitoring instance that fails with the application reports nothing.
- Match the monitor type to the failure mode. Keyword and JSON checks catch applications that fail while still returning a 200 status code.
- Use push monitors as a heartbeat for backups and scheduled jobs, where silent failure is the normal failure mode.
- Configure retries, resend behaviour, and a second notification channel, then test the alert path deliberately instead of assuming it works.
