Kuvasz: eight kinds of check, one missing feature, and a demo password in the readme

The readme publishes the demo instance's own password

There is a live demo, which is the right thing to offer, and the readme hands over its credentials in plain text: a fixed username and a fixed password, on the same page that links to the demo's status page. That is a deliberate choice for a demonstration instance rather than an oversight, but it sets the expectation for how this project treats public deployments. Anything running on a demo instance should be considered readable by anyone who has seen the readme, so no real monitor belongs there. The status page itself is linked from the same paragraph, which is a useful demonstration in its own right: you can see what a public status page looks like before deciding whether you want one for your own services, since the feature list offers both public and private pages. It is also the fastest way to judge the interface before you install anything.

Eight check types, and exactly one row where it loses

The monitoring surface is broader than the usual uptime check. Beyond HTTP requests with performance timing, there is certificate checking, a push-based heartbeat for scheduled jobs and backups, ICMP reachability with latency, TCP port checks for databases and mail and brokers, DNS resolution checks, and container checks through the container runtime. Add maintenance windows and per-monitor notification routing and the feature list is long. The comparison table at the bottom of the readme is where it becomes precise, and it has one row where the project is behind: domain expiration monitoring, which it does not offer at all while the paid tier of the service it compares against does. Everything else in that table is either a win or a tie, including a five-second interval against five minutes on the free tier, unlimited monitors against fifty, and open single sign-on against none.

Container checks read the runtime, including out-of-memory kills

The container monitoring description is the most specific line in the feature list, and it goes past the question of whether a container is running. It asserts on the health check the container itself declares, on its exit code, and on whether it was killed for exhausting memory, which is the failure people actually get paged for and the one a simple running check misses. The connection can be local or remote, and the remote path explicitly includes transport security and mutual authentication, which matters because the runtime socket is administrative rather than informational. Resource usage is optional rather than default, so a fleet of containers does not turn into a metrics firehose you did not ask for. The rest of the observability story follows the same pattern of opt-in: exporting to two metrics systems is a feature you turn on, not something the service pushes at you on install.

DNS checks can alert when records change behind you

Name resolution monitoring is described with more care than it usually gets, and one clause is worth isolating. The check confirms that a name resolves, then asserts on what came back: the record types are named, and the assertions can be exact, substring or regular-expression matches, so you can pin a specific mail exchanger or check that a verification record exists. The response code is verified too. Then comes the part that goes further than most monitors: an option to notify when the resolved records change. That turns a periodic check into change detection, which is how you find out that a domain was repointed, a mail exchanger swapped, or a verification token quietly removed. It is the kind of feature that quietly becomes the reason you keep a monitor around after the basic availability alerts stop being interesting.

Notification channels are configured per monitor, not globally

The channel list is long, which tells you the integrations are the product for a lot of users: email, two chat platforms, a messenger, a team platform, a general-purpose notification relay, a push service, an on-call service and custom webhooks. What matters more than the list is where the configuration sits. Notifications are set per monitor, so a check that pages you at three in the morning can go to one destination while a check you only glance at in the morning goes to another. Global-only routing is the most common reason people outgrow a hosted monitor: you end up muting the channel you need for something else. Maintenance windows sit alongside this and reinforce the same design, since suppression is scoped by schedule rather than by muting a whole channel. Together they are the difference between an alerting tool and a notification sink.

Maintenance windows come in three shapes

Planned downtime is a first-class feature rather than a suppression hack, and it is described three ways. A window can be set by hand, on a recurring schedule using a cron expression, or as a single one-off event, which covers both the weekly reboot window and the one-night maintenance. While a window is active the affected checks are paused rather than failed, and the alerts are suppressed, so a scheduled outage does not become a page and then a second page when someone investigates. The distinction between pausing and marking as down matters for history: a paused window leaves no failure in the record, so your uptime figures reflect real downtime. This is also the feature that most affects whether people trust a self-hosted monitor over months, because the alternative is either muting alerts and missing a real outage, or accepting noise until everyone stops reading it.

Container images come from a Java builder, not a Dockerfile

The repository has no Dockerfile, which is the first thing that surprises anyone who plans to build the images themselves. Instead there are two shell scripts that drive a Java-native image builder, and a directory of Docker examples for the other side of the story, which is running the service. There is also a Helm chart, so the Kubernetes path is chart-driven rather than manifest-driven. The code itself is a multi-module Gradle project with separate directories for the application, the domain model, shared code and the user interface, and a local development directory alongside the configuration directory. Two integrations extend it beyond its own boundary: a protocol server so an assistant can query monitor status, read incidents and create or toggle monitors in plain language, and a separate smart-home integration repository that feeds monitor state into dashboards and automations. The licence is copyleft, which is worth knowing before you fork and modify a tool you are running on your own infrastructure.

Editorial conclusion

Kuvasz suits someone who wants to self-host uptime monitoring with a five-second interval, unlimited monitors, open single sign-on and metrics export rather than a hosted service with a monitor cap. Before you migrate, read the comparison table rather than the feature list, because the one capability this project lacks is domain expiration monitoring, which the paid tier of the competitor it compares against does offer. Check the licence before you build on it, since it is copyleft and self-hosting tools get modified. And if you plan to expose a status page, remember that the readme publishes the demo instance's own credentials, which tells you how the project treats public instances.

Frequently asked questions

Official sources

1. kuvasz-uptime/kuvasz on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases