Kener

Last reviewed Sep 13, 2026 · 893 words

Kener's status page looks better than Uptime Kuma's, and that is the reason to run it. Not more monitor types, not smarter alerting, not a bigger ecosystem: a 90-day bar per service, incident timelines, maintenance windows, and theming that a customer or a family member can look at without asking what it means. It is a SvelteKit app, MIT licensed, 5,142 stars, and the catalogue's 128 MB minimum is not a typo. If the page you show other people is the product, Kener wins. If the page is a by-product of monitoring you already do, keep what you have.

Deploying it takes one container and two environment variables

The image is rajnandan1/kener and the app listens on port 3000. It stores everything in SQLite by default and can use PostgreSQL if you prefer.

services:
  kener:
    image: rajnandan1/kener:latest
    ports:
      - "3000:3000"
    environment:
      - ORIGIN=https://status.example.com
      - KENER_SECRET_KEY=generate-a-long-random-string
    volumes:
      - ./data:/app/database
    restart: unless-stopped

ORIGIN must match the public URL or form submissions in the admin area fail with a cross-site error, which is the number-one support question in the repo. The secret key signs sessions and encrypts stored credentials for monitors; lose it and you re-enter them. On first visit you create an admin account and land in the management area at /manage, where monitors, incidents, and site settings live. Older Kener releases were configured through YAML files and used GitHub issues to hold incidents; current releases keep all of that in the database with a UI, so ignore any tutorial that has you editing monitors.yaml.

The monitor types cover the common cases and stop there

Kener checks HTTP endpoints (with custom headers, methods, and body, and an evaluation script for judging the response), TCP ports, ICMP ping, DNS records, and push monitors where your own cron job or script reports in via the API. You can group monitors so a status page shows "Email" as one line backed by 3 checks. Checks run on a schedule you set per monitor, down to 1-minute intervals. What it does not do: SSL certificate expiry as a first-class check, Docker container health, database queries, or the long tail of protocol probes that Uptime Kuma accumulated over the years. For those, run the specialist and feed Kener through its push API.

Incidents and maintenance are the part worth the switch

This is where a dedicated status page earns its keep. An incident in Kener has a title, a status that moves through investigating, identified, monitoring, and resolved, and timestamped updates that render as a timeline on the public page. You can attach it to specific monitors so their bars go red for the affected period. Maintenance windows are scheduled ahead of time and show on the page before they start, which is the difference between a customer seeing "planned" and a customer filing a ticket. Monitors can also open incidents automatically when a check fails a configured number of times, and close them when it recovers.

Alerting goes out through webhooks, email, Discord, Slack, and Telegram, but the model is simpler than Uptime Kuma's 90-odd notification providers. If you already have alerts working elsewhere, leave them there.

How it compares to the tools you probably already run

Uptime Kuma is the default in the monitoring category for a reason: one container, hundreds of check types, and a serviceable public status page. Kener's page is prettier and its incident model is real rather than a status banner. Gatus takes the opposite approach, configuration-as-YAML with a functional but plain page, and is the pick for teams who want checks in git. My honest read of the status pages roundup is that most people are best served by Uptime Kuma alone until the moment they need to communicate an outage to someone who is not them; that moment is when Kener becomes worth a second container.

Young project, small ecosystem, moving fast

Kener is a 2023 project largely driven by one maintainer, which the catalogue flags and which you should weigh. It has moved through breaking config changes already (the YAML-to-database migration was one), releases arrive frequently, and there is no plugin system for third-party monitor types. For a status page that mostly reads from monitors it owns, that is manageable: the data is SQLite, the backup is one file, and if the project stalled you could stand up another page in an afternoon. I would not build an on-call process around its alerting.

What I'd do

Keep Uptime Kuma or Gatus doing the checks, and add Kener as the public face when there is a public to face: customers of a small SaaS, a club whose members use your services, a family who wants to know why the media server is down. Configure Kener's own HTTP checks for the handful of services on the page, use the push API for anything exotic, and put real incidents on it when things break so the history is honest. Behind Caddy with ORIGIN set correctly, backed up nightly, it costs less than a raspberry-pi-sized slice of a server and looks like something you paid for.