Uptime Kuma watches your other services and tells you when one stops answering. It does HTTP checks, TCP ports, ping, DNS, certificate expiry and container health, it publishes a status page you can point users at, and it speaks to around ninety notification services.

It is also the service most likely to be installed in five minutes and then quietly stop working three weeks later, for two reasons that have nothing to do with the application.

The data directory cannot live on NFS

Everything Uptime Kuma knows is in one directory inside the container: the monitors, the history, the notification credentials and the settings. That directory needs to persist, so it gets mounted somewhere.

It cannot be an NFS share. The project says so directly: map it to a local directory or a Docker volume. This catches people with a NAS, because putting application data on the NAS is otherwise the obvious move, and the failure it produces is a database that corrupts under lock contention rather than an error at startup. It works, and then one day it does not.

If the machine running the container has no local storage worth using, that is an argument for running it somewhere else, not for mounting the share anyway.

Behind a proxy, it needs WebSocket or it breaks silently

The dashboard is live; monitor states change in front of you without a refresh. That is handled by a WebSocket connection.

A reverse proxy that does not pass the Upgrade and Connection headers will serve the page perfectly. The layout appears, the monitors are listed, everything looks correct — and nothing ever updates. There is no error, because from the browser's point of view nothing failed. You are looking at a snapshot.

This is the most confusing failure in the whole setup, because the natural test — load the page, see if it works — passes. The real test is to leave the dashboard open and watch whether a monitor's state changes on its own.

Pin the version

Version 2.5.0 was released on 1 August 2026. If you track the latest tag, a major version can arrive during an unattended pull — on the one service whose job is to tell you when other things break.

Pin the major version. Upgrade deliberately, having read what changed, at a time when you are awake.

Set up notifications before you need them

A monitoring system that has detected a problem and cannot tell anyone has done nothing useful. Notifications are configured per monitor as well as globally, and a monitor created without one is silent by default.

Each integration needs its own credential, whether a bot token, a webhook URL or an SMTP account. Set up at least one and then deliberately break a monitor to confirm the message arrives. Point a check at a hostname that does not exist, wait for it to go red, and see whether your phone lights up.

Do not route alerts only through a service hosted on the machine being monitored, which is a surprisingly common arrangement. And consider a second channel for the monitors that matter: a single webhook is a single point of failure in the service meant to notice failures.

What to actually monitor

The temptation is to add everything, and the result is a wall of green that nobody reads and alerts that everyone mutes.

A more useful starting set is small. Monitor the handful of services someone would complain about within an hour, the certificates that expire, and the backup job. Certificate expiry in particular is worth adding early, because it is the outage that is entirely predictable and still happens constantly.

Keep the status page to the things a user of your services would care about. It is a different audience from the dashboard, and mixing the two makes both worse.

What a check actually proves

An HTTP monitor that accepts any 200 response is testing that a web server is running, which is a weaker claim than most people intend.

An application can return 200 from a health endpoint while its database is unreachable, its queue has stopped and its disk is full. If the endpoint being checked is a static page, the check proves the reverse proxy is up and nothing else.

Point checks at something that exercises the path you care about, and use the keyword option to require a specific string in the response. A monitor that looks for a word only present when the application has actually worked is worth ten that check for a status code.

Retries, intervals and the noise problem

The default interval is frequent enough that a brief network hiccup will produce an alert. Left alone, this trains everyone to ignore the alerts, which is worse than having none.

Set retries so that a single failed probe does not page anyone. Two or three consecutive failures before the notification fires removes most of the noise while costing you only a minute or two of detection time, and that trade is almost always right for a self-hosted service.

Lengthen the interval for things that cannot realistically break minute to minute, such as certificate expiry, which needs checking daily rather than every sixty seconds.

Where this comes from

Composed from the project's own installation and reverse-proxy documentation together with several independent published guides, cross-checked against each other on 31 August 2026. The NFS restriction and the WebSocket header requirement are both stated by the project itself; the version number will age.

Monitoring the machine from itself only goes so far. A container on the same host cannot tell you the host is down, and a status page hosted on the failed server is not reachable when you most want it. If uptime genuinely matters, the watcher belongs somewhere other than the thing being watched.