Uptime Kuma Alternative from Germany

Why does a single vantage point produce false alarms?

Because a failed request can mean two entirely different things: the service is down — or the path to it is. From a single location those cases cannot be told apart. A congested exchange, a brief route change or a DNS hiccup at your own provider looks exactly like an outage.

There are two consequences and both are expensive. The first is the 3 a.m. page for a problem that never existed. One such incident is annoying; a run of them leads to alerts being muted or ignored — and from then on the real outage is invisible too. The second is a distorted availability figure. Anyone publishing a percentage to customers is, from one vantage point, publishing a number that includes their own connectivity.

The common countermeasure is a retry counter: alert only after three consecutive failures. That helps against brief blips and simultaneously triples time to detection. It trades one problem for another, because it cannot answer the actual question — whether the problem is at the service or on the way there.

Multiple locations answer it. If Frankfurt, Vienna and Helsinki fail simultaneously, it is the service. If only Warsaw fails, it is the route. That distinction is the entire reason distributed checking exists, and it is fundamentally unobtainable from a single node — however good the software is.

In fairness: for many use cases this does not matter. Anyone monitoring internal services that are only reachable from their own network has no second vantage point available anyway, and a retry counter is the correct and sufficient answer there.

What does a free tool actually cost?

Nothing in licence, something in operation. Realistically that is a small server from around five euros a month, plus ongoing work for updates, backups, TLS certificates and the deliverability of alert emails. At two hours a quarter and an ordinary hourly rate, the annual figure exceeds what a paid plan of comparable scope costs.

This calculation is often deployed as a sales argument and is usually dishonest when it is, because it exaggerates the labour. Uptime Kuma is undemanding: one container, one data directory, occasionally a new image. Anyone already running servers has effectively paid that cost already, and the marginal cost genuinely approaches zero.

The item that is consistently underestimated is a different one: deliverability of the alerts themselves. An alert email from a self-operated instance lands in the spam folder without correctly configured SPF, DKIM and DMARC records — specifically at the large providers where the recipients actually are. The message is sent, it is delivered, and still nobody sees it. That is an alerting failure that never surfaces as an error.

For status page subscribers the same point applies at greater scale. Once you are sending to a three-figure number of recipients, deliverability becomes a discipline of its own, with warm-up, bounce handling and unsubscribe management. This is where most self-built setups buy in a third party — and from then on the bill is no longer zero.

What stays true: for fewer than ten services and an internal audience the total effort really is negligible. The calculation tips where external recipients enter the picture and where a failure of the monitoring itself stops being acceptable.

How many services can Uptime Kuma handle?

Considerably more than most installations need, but not arbitrarily many. By default Uptime Kuma stores data in SQLite; from version 2 onwards MariaDB can be configured instead. With SQLite, operators report a sluggish interface from roughly one hundred to one hundred and fifty services at short intervals, and write spikes are the limiting factor.

The write spike is the interesting part, because it occurs at exactly the wrong moment. In normal operation each run writes one result — evenly spread and uncritical. When something large fails, however, many services change state within seconds, and each change produces additional writes and notifications. Load peaks precisely when the interface is needed.

Switching to MariaDB in version 2 addresses exactly this and is the right choice for larger installations. It does add a service that itself wants backing up, updating and monitoring — the effort from the previous section grows with it.

A simple rule of thumb follows: below fifty services the default configuration is unproblematic. Between fifty and a few hundred, moving to MariaDB is worthwhile alongside an honest review of intervals — many services tolerate sixty seconds instead of twenty without anyone noticing the difference. Beyond that, the question of architecture becomes more fundamental than the question of database.