Kener vs Uptime Kuma

Kener and Uptime Kuma both run uptime checks and both publish a status page, so on paper they overlap almost completely. In practice they are built from opposite ends. Uptime Kuma's README calls it "an easy-to-use self-hosted monitoring tool": the monitor list and its "90+ notification services" are the product, and "Multiple status pages" is one bullet on the feature list. Kener's docs call it "a free, open-source status page and uptime monitor", in that order: incidents with a state timeline, maintenance windows on an RRULE, email subscribers and team roles are the product, and the monitors exist to feed the page. Which one you want depends on who is going to read it.

What each one is for

Uptime Kuma is the thing you open when something is down. One container, one web UI, and a monitor type for most things a self-hoster runs: the README lists "HTTP(s) / TCP / HTTP(s) Keyword / HTTP(s) Json Query / Websocket / Ping" and "DNS Record / Push / Steam Game Server / Docker Containers", at "20-second intervals" if you want them, with "Certificate info" and "2FA support" alongside. Its status pages are real, and you can "Map status pages to specific domains", but they are a view onto the monitors rather than a product in their own right: the wiki notes a status page "will cache results for 5 minutes", and incidents are notices you write by hand; the UI's own help text says "Pinned incidents are shown prominently on the status page".

Kener is the page your users open to find out whether it is them or you. The docs lead with "Run multiple branded status pages from a single self-hosted Kener instance", and the surrounding machinery is what a public page needs: incidents that are "records for outages or degradations that affect one or more monitors" and move through "INVESTIGATING → IDENTIFIED → MONITORING → RESOLVED"; maintenances that use "the industry-standard iCalendar RRULE format" so a weekly window is one rule, not a calendar of entries; visitor subscriptions by "email + OTP verification" for incident and maintenance mail; admin, editor and member roles; internationalization; and a REST API, since the README promises you can "Access the full REST API for incidents, monitors, and reporting". "Only monitors added to a page are shown on that page", so one instance can publish a customer page and an internal one from the same checks.

Checks and alerting

Kener runs its own checks, so it needs no monitor in front of it. The overview lists API ("HTTP/HTTPS checks with custom eval logic"), Ping, TCP, DNS, SSL, SQL, Heartbeat ("Push-based health signal"), GameDig, gRPC, Docker, Prometheus and Group ("Weighted aggregate of member monitors"), on cron expressions, with a DEGRADED state for a check that "succeeded but is unhealthy by your logic/threshold". Coverage overlaps heavily: Uptime Kuma also has gRPC, SQL (MySQL, PostgreSQL, SQL Server), MongoDB, Redis, GameDig and group monitors behind the README's short list, plus keyword and JSON-query checks Kener lacks; Kener's distinct additions are Prometheus queries and SSL expiry as a monitor type of its own.

Alerting is where the two part. Uptime Kuma's notification list is the longest in our monitoring hub: Telegram, Discord, Gotify, Slack, Pushover and SMTP are named in the README, with "90+ notification services" behind them and Apprise for the rest. Kener's triggers page says the runtime "currently supports:" four types, webhook, discord, slack and email, where "Triggers are delivery channels used by alert configurations" and "Trigger bodies/subjects can use Mustache variables". An alert configuration is per monitor and counts "consecutive failing evaluations before TRIGGERED", with a matching success threshold before RESOLVED, and it can open an incident on the page automatically. So Kener's four channels are enough to reach an on-call chat and to update the public page without a human, but anything beyond Slack, Discord or email is a webhook you template yourself; Uptime Kuma has a native integration for nearly everything, including the self-hosted push servers.

Maintenance windows exist on both. Uptime Kuma's are "designed for" two things, to "Temporary disable notifications during a time window" and to "Show a maintenance message on status pages", and affected monitors "will be displayed in blue on the Dashboard and all display status pages during the maintenance". Kener's go further: "When a maintenance event is ONGOING, the specified impact overrides the monitor's realtime status on the status page", and subscribers get mail when a window is about to start, starts and completes.

Checking from somewhere else

Neither tool runs probes from several regions on its own. Uptime Kuma's maintainers have kept the "Remote Executors" request open for years and are blunt about scope: "No HA is not planned." and "This issue is for remote monitors only." The same comment carries the advice that matters for both tools: "you should not co-locate your uptime status page on the same infrastructure, datacenter or credit card." The 2.x line adds a Globalping monitor, which "provides access to thousands of community hosted probes to run network tests and measurements" through a third-party service, one location per monitor ("Multiple locations are not supported, please use a single location for each monitor."); our snippet pins the 1.x image, which does not have it. Kener's docs say nothing about where checks run from, so assume the Kener server.

Footprint and setup

Uptime Kuma is one container, one volume, port 3001, SQLite inside the volume. Kener is two containers: Kener itself and a Redis it "will not start without REDIS_URL" for, in the docs' words, "queues, caching, and scheduling". Kener's own data "Defaults to SQLite if omitted" in the mounted database directory, with "PostgreSQL (recommended for production)" or MySQL through DATABASE_URL, and it needs ORIGIN set to the "Public URL, no trailing slash" before anyone can sign in. Kener's Redis setup page sizes the app at about 512 MB minimum and 1 GB recommended, plus 128 to 256 MB for Redis, which lands on our 512 MB floor; Uptime Kuma's README gives no minimum, so its 512 MB is our estimate. In our install checks (GCP e2-standard-2, Ubuntu 26.04, September 2026 for Uptime Kuma and October 2026 for Kener), Uptime Kuma idled at ~104 MB of RAM and ~692 MB of disk; Kener, with the Redis it requires, idled at ~401 MB of RAM and ~845 MB of disk. Both are plain HTTP behind a reverse proxy. We rate both 1 out of 5 to deploy.

Which to choose

Choose Uptime Kuma if the audience is you: one container at ~104 MB, a monitor type for most of what you run, "90+ notification services" so the alert lands wherever you already look, and status pages good enough for a household or a small team.

Choose Kener if the audience is your users: a branded public page with staged incidents, RRULE maintenance windows that override live status, email subscribers with OTP verification, team roles and a REST API, fed by its own API, ping, TCP, DNS, SSL and heartbeat checks, and you accept a Redis container, four alert channels plus webhooks, and roughly four times the idle RAM for it.

Running Kener or Uptime Kuma on a VPS

Both installs are verified on Ubuntu 26.04; the one-line docker run is on the Uptime Kuma page and the trimmed two-service compose with a generated KENER_SECRET_KEY is on the Kener page. Put either behind a TLS reverse proxy, and for Kener make ORIGIN the address people will actually use, or the sign-in form fails its CSRF check. Running both is not silly: Uptime Kuma as the alerting console you watch, Kener as the page you publish. If what you really want is the monitor list in git rather than a web UI, that is Uptime Kuma vs Gatus.