Kener is a self-hosted status page and uptime monitor written in SvelteKit and Node.js. It aims at the gap between a plain uptime script and a commercial incident platform: you define the checks you care about, Kener polls them, and it publishes a branded public page showing which services are up, how they have behaved over the past ninety days, and what you have said about the outages. The project is MIT licensed, recently shipped version 4.2.1, and runs either from a Docker image or from source against a Redis instance.

Monitoring coverage

Checks are not limited to HTTP. Kener ships monitor types for API endpoints, ICMP ping, TCP ports, DNS records, TLS certificate expiry, SQL queries, heartbeat pings that your own cron jobs call back into, and GameDig queries for game servers. Monitors can be grouped so a composite entry rolls up the state of several children, and the default check interval, retry count and timeout are set per monitor rather than globally.

The public page reports the numbers each monitor collected: uptime percentage over the selected window, response time in milliseconds, and a per-day bar chart where a degraded or failed day is visible at a glance. Historical data stays in Kener’s own database, so trends survive restarts and are not dependent on an external time-series service.

Incidents and maintenance

Incidents are first-class objects with a timeline of updates, a state that moves between investigating, identified, monitoring and resolved, and acknowledgements for the people on call. A single incident can be attached to several monitors, and the update text is what subscribers see, so writing the incident is the same act as communicating it. Scheduled maintenance windows are configured up front with a start and end, and recurring maintenance keeps its local wall-clock time across clock changes rather than drifting by an hour twice a year.

Notifications

State changes can be pushed out over email, generic webhooks, Slack and Discord. Notifications are built from templates rather than fixed strings, and trigger-based workflows allow different recipients or channels to be used depending on which monitor failed or how long it has been down, which keeps a noisy check from paging the whole team.

Pages, branding and embeds

One Kener instance can serve several status pages, each with its own monitors, layout, logo, colours and custom CSS. Pages support light and dark themes, localisation, timezone-aware timestamps and subscriber sign-up. Status widgets and badges can be embedded in an external site or internal portal, and the public pages are server-rendered with their own metadata so they are indexable rather than a client-side blank.

Administration and integration

Administration is done from a web UI: create monitors, edit pages, invite team members with role-based permissions, and manage API keys for automation. A REST API covers incidents, monitors and reporting, so Kener can be driven from scripts or CI. Optional analytics integrations exist for Google Analytics, Plausible, Mixpanel, Umami and Microsoft Clarity.

Deployment

The documented path is Docker. A compose file brings up Kener and Redis together; standalone images are published as docker.io/rajnandan1/kener and ghcr.io/rajnandan1/kener, with separate tags for subpath deployments under /status. A strong KENER_SECRET_KEY and the correct ORIGIN must be set before the first start. Running from source needs Node.js 24.14 or newer plus Redis, followed by npm run build and npm run start. Configuration is environment-based; there is no external database server to provision.

Licence

MIT licensed. Source at github.com/rajnandan1/kener, documentation at kener.ing.