Kuvasz: Self-Hosted Uptime, SSL, DNS and Heartbeat Monitoring in Kotlin

The gap Kuvasz fills: monitoring you own, at a five second interval

Hosted uptime services charge by monitor count and by check frequency. The README's own comparison table puts Kuvasz at a 5-second monitoring interval with unlimited monitors, against 5 minutes on the UptimeRobot free tier and 60 seconds on the paid Solo tier. That gap is the whole argument. If you need to know within seconds that a checkout endpoint stopped answering, a 5-minute polling cycle is not a monitoring system, it is a postmortem aid. Kuvasz targets the operator who wants that resolution without a per-monitor bill, and who is willing to run the service themselves. The audience is fairly specific: platform and SRE teams already running containers and a database, homelab operators who want the same feature set at home, and anyone who needs the monitoring data to stay inside their own network. The repository description lists cloud-native, containerized, homelab and IaC-managed among its topics, which matches that reading. It is not a hosted product and it is not trying to be one.

Six check types, each with its own failure semantics

Kuvasz is not only an HTTP pinger. The README enumerates HTTP(S), SSL certificate, heartbeat (push), ping (ICMP), TCP port and DNS monitoring. Each has distinct failure semantics, and that matters more than the list. An HTTP check can assert on keyword matches, response headers, a custom status matcher, custom HTTP methods, custom request headers and a custom request body, and it can raise a slow-response alert. The SSL check watches certificate validity and expiry. Heartbeat monitoring inverts the direction: your cron job or backup script pushes to Kuvasz, and an alert fires when the expected heartbeat does not arrive, which is the correct model for scheduled work that may simply never run. TCP checks confirm that a database, SMTP, SSH or message broker port accepts connections and track connect latency. DNS checks assert on returned records (A, MX, TXT, NS and others) with exact, substring or regex matchers, verify the response code, and can notify you when resolved records change. That last capability is the one most hosted tools do not offer at this price point, and it is genuinely useful for catching a hijacked or accidentally edited zone.

How configuration and data actually flow

The architecture visible from the repository is a Kotlin service built on Micronaut, packaged as a container, with monitors defined as YAML and managed either through those files or through the REST API. The README describes the project as IaC-managed and lists backups and YAML configuration as a differentiator against UptimeRobot, so the intended workflow is that your monitor definitions live in version control and are applied to the running instance rather than clicked into a web form. Alongside that, the service exposes a full REST API and an MCP server, and the MCP server is described as letting an AI assistant query monitor status, view incidents, and create or toggle monitors through natural language. Metrics leave the system through OpenTelemetry and Prometheus exporters, which is the integration point that matters if you already run Grafana or a compatible backend. Notifications are configured per monitor, so a database TCP check and a marketing site HTTP check can route to different channels. The supported channels listed are email, Discord, Slack, Telegram, Microsoft Teams, Apprise, Pushover, PagerDuty and custom webhooks. Status pages can be public or private, and maintenance windows can be scheduled manually, on a recurring cron schedule, or as a one-off, during which the affected checks pause and alerts are suppressed.

Getting it running: what the documentation actually tells you

The README does not inline a docker run command. It points to the deployment guide at kuvasz-uptime.dev/setup/installation/ and says to refer to it for the quick start, so the exact compose file, image tag and environment variables have to be read there rather than here. What the README does give you is a live demo at demo.kuvasz-uptime.dev with the credentials demo and secureDemoPassword, which is the fastest way to see the UI and the status page rendering before you commit to a deployment. The container image is published as kuvaszmonitoring/kuvasz on Docker Hub, which is the image name to look for in the guide. Configuration keys are not enumerated in the README either; the YAML schema for monitors is documented on the same site. If you are evaluating this for a team, the honest sequence is: log into the demo, read the installation page, then check whether the exporters section of the docs lists the metric names your existing dashboards query. That third step is where most adoptions either clear or stall, and it cannot be answered from the README alone.

The deployment burden is the price of the feature set

Self-hosting a monitor means you are now responsible for the thing that tells you when other things are broken. If Kuvasz runs on the same host or the same network as the services it watches, a network partition or a host failure takes out both the service and its observer, and you learn about the outage from your users. The README does not claim any high-availability or multi-node story, and nothing in the supplied material suggests the checks run from multiple vantage points by default. The comparison table marks location-specific monitoring as available with an asterisk, which implies a caveat the table does not spell out. Treat single-instance deployment as the default assumption and plan accordingly: run it somewhere that fails independently of your production stack. The second constraint is the database. The supplied material does not state which database Kuvasz requires or how it is provisioned, so verify that before you size a host. Third, the 5-second interval is a capability, not a recommendation. Pointing a 5-second HTTP check at an endpoint you do not control is a good way to get rate-limited or blocked, and the project gives you no automatic backoff that the README describes. Finally, the MCP server is a recent addition and the README presents it as a way to create and toggle monitors through an AI assistant. That is a write-capable interface driven by natural language. Whether you expose it, and to whom, is a security decision the documentation does not make for you.

Kuvasz against UptimeRobot, and against running nothing

The README's comparison table is the project's own framing, so read it as a positioning statement rather than a neutral benchmark. The real difference in approach is not the feature checkmarks, it is where the checks originate and who holds the data. UptimeRobot probes your endpoints from outside your infrastructure, which is exactly what you want when the failure mode you fear is your own network or hosting provider going dark. Kuvasz runs wherever you put it. Those are different products solving overlapping problems, and the choice depends on which failure you are actually trying to detect. If your concern is a cloud region outage, an external probe is structurally better and no amount of self-hosting changes that. If your concern is an internal service, a database port, a DNS record, or a cron job that silently stopped, an external SaaS cannot see those at all. The other alternative is running nothing beyond what your existing stack already provides. If you already run Prometheus, the blackbox_exporter plus Alertmanager covers HTTP, TCP and ICMP probing, and you may not need a second system. Kuvasz's advantage over that combination is the parts blackbox_exporter does not give you: status pages, maintenance windows, per-monitor notification routing, heartbeat ingestion and a UI. If you have none of those needs, the exporter route is fewer moving parts.

Licence, upgrade cadence and what maintenance costs you

Kuvasz is licensed under AGPL-3.0. That is a copyleft licence with a network clause: if you modify the software and let users interact with it over a network, the licence requires you to offer those users the corresponding source. Running an unmodified container internally does not trigger that obligation in the ordinary case, but the moment you patch the code and expose it, you are in different territory. This is a description of the licence, not legal advice; if you plan to modify and redistribute, talk to someone qualified. On maintenance, the release history shows a steady cadence: 4.3.0 and 4.3.1 both landed on 2026-08-31, and 4.3.2 followed on 2026-09-04. Patch releases arriving days apart suggests active bug fixing, and it also means you should not pin to a single patch version and forget it. The upgrade path is a container image pull plus whatever database migrations the release notes describe, so the operational cost is bounded but recurring. The repository also carries a badge stating zero percent vibe coding, which is a stylistic claim rather than a technical guarantee, and it tells you the maintainers care about how the code was produced. What the material does not tell you is the size of the maintainer group or how bus-factor risk looks. That is worth checking on the repository itself before you make this a load-bearing part of your alerting.

Editorial conclusion

Adopt Kuvasz if you want a self-hosted monitor whose configuration lives in YAML and whose metrics land in Prometheus or OpenTelemetry, and if you accept running the database and the container yourself. Do not adopt it for one-off external probes against a public endpoint, or if you cannot take on the AGPL-3.0 obligations around modified network-facing code. Before committing, verify three things against the current documentation: that the exporters expose the metrics your dashboards need, that the notification channels you rely on are all present, and that your Postgres version is supported.

Official sources

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