Uptime Kuma Self-Hosting Guide: Monitoring, Alerts, Status Pages, Backups & Safe Deployment

By AiCybr Editorial · Published August 11, 2026

Uptime Kuma is a strong default for homelabs and small self-hosted environments when the primary question is simple: “Is this service reachable, healthy enough to answer, and should I be alerted?” It is not a replacement for Prometheus, Grafana, logs, traces or application performance monitoring. Its strength is fast deployment, straightforward availability checks, flexible notifications and simple public or private status pages.

For a reliable setup, the most important decisions are not the dashboard theme or number of monitors. Put Uptime Kuma in a failure domain that is useful, persist /app/data on local storage, back up that data directly, avoid exposing the Docker socket unless you genuinely need container-state monitoring, and test the notification path independently of the service being monitored.

Uptime Kuma 2.5.0, released on August 1, 2026, is the current stable release at the time of writing. Version 2.5.0 adds an NTP monitor and several notification and operational changes, but the deployment principles below matter more than any single release feature.

Quick recommendations

What Uptime Kuma is good at

Uptime Kuma’s current README lists monitoring for HTTP(S), TCP, HTTP keyword checks, JSON queries, WebSocket, ping, DNS records, push monitors, Steam game servers and Docker containers. It also supports certificate information, multiple status pages, two-factor authentication and more than 90 notification integrations.

That makes it particularly useful for questions such as:

• Is my website returning a successful response?
• Does the login page contain the expected text?
• Is a TCP service accepting connections?
• Does a DNS record resolve correctly?
• Is an internal API returning the expected JSON state?
• Is a TLS certificate approaching expiry?
• Did a scheduled job successfully send a heartbeat?
• Is a Docker container running?

The distinction between availability monitoring and observability matters. Uptime Kuma can tell you that an endpoint is down or slow enough to fail a configured check. It does not, by itself, explain CPU saturation, query latency, memory pressure, distributed traces or why a request became slow. For those questions, pair it with metrics, logs or traces rather than trying to force one tool to do every job.

Recommended Docker Compose deployment

The official project provides a Docker Compose installation path. A minimal deployment looks like this:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - ./data:/app/data

Then start it with:

docker compose up -d

For a host that will only be reached through a local reverse proxy, VPN or tunnel, consider binding the service to localhost instead of every network interface:

ports:
  - "127.0.0.1:3001:3001"

The official documentation specifically warns that NFS is not supported for Uptime Kuma’s data directory. Keep /app/data on a local filesystem or Docker volume. If you need remote backup, replicate or back up the local data rather than making the live SQLite-backed application state depend on network storage.

Choose monitors by what users actually depend on

A common monitoring mistake is checking a component instead of the service outcome.

Suppose a web application runs in Docker. A Docker monitor can tell you whether the container is running. That is useful, but it does not prove that the application is serving valid responses. The process may be alive while its database connection is broken, a migration failed, or the web server is returning HTTP 500.

For most applications, an HTTP(S) check should therefore be the primary monitor. Add container-state monitoring only when it provides additional diagnostic value.

HTTP and HTTPS monitors

Use these for websites, web applications, APIs and reverse-proxied services. A successful TCP connection alone does not guarantee a functioning application, so HTTP checks are generally more meaningful for user-facing services.

For important applications, monitor a lightweight endpoint designed to represent application health rather than a large homepage with many third-party dependencies.

Keyword and JSON checks

A normal HTTP 200 response can still contain an error page or degraded application state. Keyword or JSON-query checks can verify a specific expected result.

Use these carefully: a brittle keyword tied to page copy can create false alerts after harmless UI changes. Prefer a stable health endpoint or machine-readable response where possible.

TCP monitors

Use TCP when the relevant question is whether a network service accepts a connection on a port and an application-level protocol check is unavailable or unnecessary.

Examples include certain databases, brokers or custom services. A successful TCP connection proves less than a protocol-specific health check, but it is often better than no check at all.

DNS monitors

DNS checks are useful when name resolution is itself part of the service contract. They can help distinguish an application outage from a DNS problem.

For public services, consider monitoring both the application and its DNS record. That makes triage faster when only one layer fails.

Push monitors

Push monitors invert the normal model: instead of Uptime Kuma polling a target, a scheduled job sends a heartbeat to Uptime Kuma. They are a good fit for backups, cron jobs, ETL tasks and other work that should complete on a schedule.

The important design principle is to alert on missing success, not merely on a process starting. Send the heartbeat only after the job has reached the success condition you care about.

NTP monitor in Uptime Kuma 2.5.0

Version 2.5.0 adds an NTP monitor type. This is useful for infrastructure where time synchronization matters, including authentication systems, certificate validation, distributed systems and logging pipelines.

Do not interpret an NTP monitor as proof that every client on your network has correct time. It verifies the configured NTP target; client synchronization still needs its own operational controls.

Alert design: avoid creating a noisy dashboard

Monitoring becomes less useful when every transient packet loss event creates an alert.

Start by deciding what deserves a human interruption. A public website may justify faster checks than an archival NAS dashboard. Internal services may tolerate a longer confirmation window if a one-minute delay has little operational cost.

Useful alert-design principles include:

1. Do not use the shortest interval simply because it is available. Uptime Kuma supports short polling intervals, but more frequent checks increase request volume and sensitivity to brief network events.
2. Separate critical and informational monitors. A failed DNS resolver or authentication service deserves different handling from a nonessential dashboard.
3. Use dependency-aware thinking even when the tool does not model your entire dependency graph. If ten services all depend on one reverse proxy, ten simultaneous alerts may represent one root cause.
4. Test recovery notifications as well as failure notifications. Otherwise you may know a system failed but not notice when service returned.
5. Test the notification provider itself. An alert configuration that has never been exercised is not yet trustworthy.

Keep the notification path independent

A monitoring system can become useless during the exact outage it is supposed to detect if the alert path depends on the failed infrastructure.

For example, if Uptime Kuma monitors your self-hosted email stack but sends alerts only through that same email stack, a mail outage can suppress its own notification.

Where possible, use at least one alert channel with an independent failure path. That could be an external push service, hosted email provider, messaging platform or another service that does not depend on the same server, DNS zone, internet connection or power circuit as the monitored target.

For high-value services, periodically test the end-to-end path by intentionally failing a harmless monitor.

The failure-domain problem: where should Uptime Kuma run?

This is the most important architectural question in many self-hosted deployments.

Running Uptime Kuma on the same Docker host as every monitored application is convenient and perfectly reasonable for low-consequence homelabs. It will detect many application-level failures. But if the host loses power, its storage dies, Docker stops, or the local network disappears, Uptime Kuma disappears too.

That means the ideal location depends on what you are trying to detect.

For many users, two layers make sense: local monitoring for internal services and an external check for a small number of public or business-critical endpoints.

Docker monitoring and the docker.sock security tradeoff

Uptime Kuma supports Docker-container monitoring, but the official project documentation includes an important warning: giving the Uptime Kuma container access to /var/run/docker.sock gives it powerful access to the Docker daemon. If that container is compromised, the impact can extend well beyond the monitoring application.

A typical Docker-socket mapping looks like this:

volumes:
  - /var/run/docker.sock:/var/run/docker.sock

Do not add it automatically.

Ask whether container state actually tells you something you cannot learn more safely. For a web service, an HTTP health check usually provides a better user-centric answer without Docker-daemon access. For a background container with no network endpoint, Docker state may be useful, but the privilege tradeoff should be explicit.

If you use Docker monitoring, avoid exposing the Uptime Kuma dashboard directly to the public internet, keep the application updated, use strong authentication, and minimize other unnecessary access paths.

Status pages: useful, but deliberately public information

Uptime Kuma supports multiple status pages and custom domain mappings. The project’s status-page documentation notes that public status pages are intended for users to check service status and that displayed information is cached/refreshed rather than acting like the real-time administrative dashboard.

A public page can be useful for websites, APIs, SaaS services, game servers or community infrastructure. It can also reveal operational information you did not intend to publish.

Before adding an internal service, ask whether its hostname, function, outage history or maintenance state should be public. An internal database, admin panel, backup server or authentication backend rarely needs a public status page simply because it is being monitored.

For private environments, the dashboard itself may be enough.

Backups: protect /app/data, not just the UI configuration

Uptime Kuma’s own application strings warn that its older built-in backup feature is deprecated/incomplete and recommend backing up the volume or data directory directly instead.

For Docker deployments, that means the persistent state mounted at:

/app/data

A practical backup workflow is:

1. identify the host directory or Docker volume that backs /app/data;
2. create a consistent backup of that storage;
3. keep at least one copy outside the monitoring host;
4. record the image/version used at backup time;
5. test restoration into a disposable container or VM.

Do not treat RAID, ZFS redundancy or a mirrored disk as a backup. Those mechanisms can improve availability but do not protect you from accidental deletion, corruption propagated across replicas, compromise or losing the whole host.

Should you stop Uptime Kuma before backup?

A stopped application produces the simplest possible filesystem backup because no writes are in progress. If your backup tool can create an application-consistent filesystem snapshot, that may reduce downtime. The safest method depends on the storage platform and backup mechanism.

What matters most is not claiming success because a backup file exists. Periodically restore it and verify that monitors, notification settings and status pages are present.

Upgrades and version pinning

The Uptime Kuma security page currently recommends upgrading to the latest supported version. For Docker, the project lists the 2, 2-slim, next, next-slim, 2-rootless and 2-slim-rootless families with different support roles, while older version-1/latest-style tags are deprecated or not the preferred path.

For a small homelab, following the supported major-version 2 tag may be convenient. For environments where change control matters, pinning a specific release gives you more control over when an upgrade occurs.

A conservative upgrade procedure is:

1. back up /app/data;
2. read the release notes and breaking changes;
3. pull the intended image;
4. recreate the container;
5. verify dashboard login, monitors and notifications;
6. trigger a test alert;
7. retain a rollback path until the new version is proven.

Do not rely on an image downgrade as a database rollback strategy unless the project explicitly documents that path. A pre-upgrade data backup is the safer recovery point.

Reverse proxy, VPN or direct exposure?

The official install instructions expose port 3001 by default, but that does not mean it should automatically be reachable from the internet.

For a private homelab, good options include:

• bind Uptime Kuma to localhost and publish it through a reverse proxy;
• keep it LAN-only;
• access it through WireGuard, Tailscale or another VPN;
• place authentication controls in front of it where appropriate.

If you expose a public status page, that does not require the administrative dashboard to share the same exposure model. Treat the management interface and the public status surface as separate security decisions.

Uptime Kuma vs Prometheus and Grafana

These tools overlap less than their dashboards suggest.

A useful combined architecture is Uptime Kuma for service availability and user-visible status, plus Prometheus/Grafana or another observability stack for detailed metrics and diagnosis.

A practical monitor set for a homelab

A small environment does not need hundreds of checks to be useful. A focused set might include:

• external HTTPS check for the public domain;
• internal HTTPS check for the application origin;
• DNS check for the public record;
• certificate-expiry monitoring;
• push monitor for the nightly backup job;
• HTTP check for Immich, Jellyfin, Nextcloud or another key application;
• TCP or service check for critical infrastructure that lacks a health endpoint;
• router/internet reachability check from a suitable monitoring node;
• optional Docker-state check only where it adds diagnostic information.

The goal is to make an alert actionable. If a check fails and you would not investigate or change anything, reconsider whether it needs to alert at all.

Where Uptime Kuma fits best

Uptime Kuma is particularly compelling when you want:

• a self-hosted alternative to basic hosted uptime-monitoring services;
• a clean dashboard without building a complete metrics stack;
• quick HTTP, TCP, DNS, push and certificate checks;
• many notification-provider options;
• simple public status pages;
• lightweight monitoring for a homelab, personal server or small service portfolio.

It is less suitable as the only monitoring system when you need deep infrastructure metrics, high-cardinality telemetry, distributed tracing, detailed SLO analysis, large-scale multi-team observability or sophisticated event correlation.

Final recommendation

For most self-hosters, deploy Uptime Kuma on reliable local storage, start with a small number of outcome-focused monitors, configure at least one independent notification channel, and back up /app/data directly. If monitoring the failure of the main host or internet connection matters, move the monitor into a separate failure domain or add an external checker.

The two most avoidable mistakes are giving the container unnecessary Docker-daemon access and hosting the monitor inside the same failure boundary you expect it to report on. Solve those first; monitor count, themes and dashboard organization come later.

Sources

• Uptime Kuma repository and installation documentation
• Uptime Kuma 2.5.0 release notes
• Uptime Kuma status-page documentation
• Uptime Kuma Docker-container monitoring documentation
• Uptime Kuma security and supported-version policy