Kuvasz is an open-source, self-hosted uptime and SSL monitoring service written in Kotlin, built for teams, homelab operators and infrastructure engineers who want to watch their websites, services and TLS certificates on infrastructure they control rather than on a vendor's platform.

What it is

Kuvasz is a monitoring service that checks the availability and performance of the things you run. It speaks several protocols to do that: HTTP(S) requests against websites and APIs, SSL certificate inspection to confirm a certificate is valid and unexpired, ICMP echo requests for reachability and latency, TCP connection attempts against services such as databases, SMTP, SSH and message brokers, DNS lookups with assertions on returned records, and heartbeat (push) monitoring for cron jobs and backups that are expected to report in on schedule. Results surface in a modern web interface, through a REST API, and through a status page that can be published publicly or kept private for an internal team.

The concrete problem it replaces is the split between a paid uptime SaaS and a pile of standalone scripts. Instead of paying a hosted vendor per monitor and per seat, or wiring together separate certificate expiry checks, cron heartbeat receivers and DNS watchers, a single self-hosted service covers all of those check types and routes alerts from one place. It lives in the cloud-native and containerized ecosystem, is distributed as the Docker image kuvaszmonitoring/kuvasz, and is licensed under AGPL-3.0. Configuration can be managed declaratively as YAML, which makes it fit infrastructure-as-code workflows alongside the rest of a stack.

Key capabilities

• HTTP(S) monitoring of availability and performance for websites and services, plus automatic SSL certificate validity and expiry checks.
• Heartbeat push monitoring for cron jobs, backups and scheduled tasks, with alerts when an expected heartbeat fails to arrive.
• ICMP ping, TCP port and DNS monitoring, including assertions on A, MX, TXT and NS records using exact, substring or regex matchers, with optional alerts when resolved records change.
• Notification channels configured per monitor, covering email, Discord, Slack, Telegram, Microsoft Teams, Apprise, Pushover, PagerDuty and custom webhooks.
• Public or private status pages, plus maintenance windows to suppress noise during planned work.
• A full REST API and an MCP server, the latter allowing AI assistants to query monitor status, view incidents and create or toggle monitors.
• Metrics exporters for Prometheus and OpenTelemetry, and an official Home Assistant integration (ku-hass) for smart home dashboards and automation.

Who uses it and how

• Homelab operators running containerized services who need uptime and certificate checks without a hosted subscription.
• Platform and SRE teams that manage monitor definitions as YAML in version control, treating monitoring config as infrastructure as code.
• Teams that publish status pages to keep users or internal stakeholders informed during incidents, using the same alert routing that drives their on-call channels.
• Operations groups that already run Prometheus and OpenTelemetry, exporting Kuvasz metrics into an existing observability stack.
• Home Assistant users who want service status visible on a smart home dashboard and automated actions triggered by it.

Getting started

Kuvasz runs from the Docker image kuvaszmonitoring/kuvasz, with the official Deployment guide in the documentation at kuvasz-uptime.dev/setup/installation/ covering installation. A live demo instance is available at demo.kuvasz-uptime.dev, using the credentials demo / secureDemoPassword.

How it compares

The facts provided for this page name no paid products that Kuvasz replaces, and no competing tools appear in its topic or feature list, so it stands alone in this registry. Prometheus, OpenTelemetry and Home Assistant appear only as integrations it exports to or plugs into, not as alternatives.

When to use it — and when not to

Kuvasz suits anyone willing to operate the service themselves, including whatever database, storage and mail configuration the deployment guide requires, since none of those requirements are spelled out in the repository README. It is the wrong choice for teams that want a managed SaaS with no operational surface, and the AGPL-3.0 licence is a consideration for anyone planning to embed it in a proprietary product. The clearest weakness in the facts is documentation depth: the README excerpt is short and defers setup, configuration and operational detail to the external documentation site.