Kener

Kener is an open-source status page and uptime monitoring system built with SvelteKit 5 and Node.js that lets teams self-host a beautiful, fully branded public status page without depending on expensive SaaS platforms. It ships with 11 monitor types — from API and Ping to gRPC, SQL, GameDig, and SSL certificate checks — with configurable cron schedules, confirmation thresholds, and per-monitor alerting that keeps the right people informed at the right time.

Designed to be operationally lean, Kener runs inside a single Docker container with Redis for job queuing and a SQLite or PostgreSQL database for persistence. Version 4 brought a ground-up rewrite with a full-featured REST API, role-based access control, multi-page support for hosting separate status pages per product or region from one instance, and an embedded subscription system that notifies end-users via email when incidents or maintenance windows are created.

Kener’s admin dashboard is built with Svelte 5 and shadcn-svelte, giving it a polished, responsive interface for managing monitors, incidents, maintenance schedules, and team members. Embeddable widgets and SVG badge endpoints make it easy to surface live service status inside documentation portals, GitHub READMEs, and support sites — all without JavaScript dependencies on the embedding site.

With 83 releases since December 2023 and an active release cadence of roughly three releases per month, Kener has matured quickly into a production-ready alternative to Atlassian Statuspage, BetterStack, and Freshstatus for teams that require full data sovereignty and customizable branding.

What You Get

• 11 Monitor Types - Execute API, Ping, TCP, DNS, SSL certificate, SQL query, Heartbeat, GameDig, gRPC, and Group checks with per-monitor cron schedules and confirmation thresholds to eliminate flapping alerts.
• Incident Lifecycle Management - Create incidents with rich timelines, post timestamped updates, acknowledge issues, and track resolution — with subscriber notifications at every stage via email.
• Maintenance Windows with RRULE Scheduling - Define recurring maintenance windows using RFC 5545 recurrence rules, configure per-monitor impact levels (UP, DEGRADED, DOWN, MAINTENANCE), and auto-notify subscribers before, during, and after downtime.
• Multi-page Status Dashboard - Host separate, independently branded status pages for different products, teams, or regions from a single Kener deployment, each with its own monitors and incident history.
• Multi-channel Notifications - Dispatch alerts to Email, Webhook, Slack, and Discord through trigger-based workflows tied to status transitions, with reusable Mustache message templates to standardize communication.
• Embeddable Widgets and SVG Badges - Embed live status cards via HTML snippets and link to static SVG badge endpoints that update dynamically without requiring JavaScript on the embedding page.
• Full REST API (v4) - Automate monitor management, incident creation, maintenance scheduling, and status queries across all resources with a versioned REST API documented via Scalar and accessible with API key authentication.
• Role-Based Access Control - Invite team members with Admin, Editor, or Viewer roles to collaborate on monitors and incidents through the admin dashboard with scoped permissions enforced at the server hook level.
• Secrets Vault - Store API keys, credentials, and environment variables for use in monitor configurations and webhook payloads without exposing them in the UI or source control.
• End-user Subscription System - Let visitors subscribe to status page updates via email so they receive incident and maintenance notifications automatically without requiring an account.
• Analytics Integrations - Connect Google Analytics, Plausible, Mixpanel, Umami, or Microsoft Clarity to track how visitors interact with your public status page.
• Custom Branding and Theming - Upload a logo, set custom colors and CSS overrides, choose light or dark mode defaults, and configure timezone-aware display to match your product’s identity.

Common Use Cases

• SaaS API transparency - A developer tools company deploys Kener to host a public status page for their API, with embeddable badges in their documentation portal and email subscriber notifications that fire automatically when incidents are created.
• Multi-product operations team - A platform engineering team creates separate Kener status pages for each of their customer-facing products within a single instance, with different branding and monitor sets per page and per-team RBAC.
• Self-hosted compliance monitoring - A fintech startup required by contract to avoid third-party SaaS data processors runs Kener on-premises with PostgreSQL, keeping all uptime telemetry and incident records inside their own infrastructure.
• Game server monitoring - An online game studio uses Kener’s GameDig monitor type alongside TCP and API checks to surface real-time server health and player-visible maintenance windows on a branded status page.
• Open-source project health page - A solo developer uses Kener’s free tier with the Docker Compose quickstart to host a public status page for their open-source tool’s hosted demo, linking SVG uptime badges in the GitHub README.

Under The Hood

Architecture Kener’s architecture separates public status delivery from backend monitoring execution through SvelteKit’s route group system, which partitions the application into distinct surfaces: a public-facing Kener view, an authenticated management dashboard, a versioned REST API, and embeddable widget endpoints. Server logic is organized into a repository pattern layered over Knex, a schedulers layer that manages cron-driven monitor execution and maintenance windows, and a BullMQ queue system that decouples monitor execution from result processing and notification dispatch. Server hooks enforce authentication and resource ownership at the framework boundary, injecting resolved monitor tags, incident IDs, and page slugs into request locals before route handlers run. This design means access control is consistent regardless of which API path is called and avoids duplicating authorization logic across individual endpoints.

Tech Stack Kener runs on Node.js 20+ and is built with SvelteKit 5 using Svelte’s rune-based reactivity model, compiled and bundled by Vite 7. The UI component layer uses shadcn-svelte (bits-ui primitives) and Tailwind CSS v4 with utility variants for theming. The persistence layer supports SQLite via better-sqlite3 for lightweight deployments and PostgreSQL via the pg driver for production workloads, with Knex managing schema migrations and query building. Redis is a required dependency used via ioredis and BullMQ for job scheduling, result queuing, and cache storage. Monitor protocol implementations cover HTTP, TCP, DNS via dns2, SSL certificate inspection, gRPC via @grpc/grpc-js, SQL queries via mysql2 and pg, ICMP ping, and GameDig for game server protocols. Notifications are dispatched through Nodemailer (SMTP/Resend), native Slack and Discord webhook payloads, and configurable generic webhooks. The build pipeline compiles the SvelteKit app with the Node adapter and bundles the standalone server entry via esbuild, producing a self-contained build/main.js artefact.

Code Quality The codebase maintains strong TypeScript coverage across its server layer, with well-defined interfaces in a dedicated types directory covering database records, monitor configurations, API schemas, and result shapes. Repository classes inherit from a typed base that wraps Knex, providing consistent query patterns and centralizing data integrity rules such as confirmation threshold clamping at the persistence layer. Error handling is explicit in service call implementations, with each monitor type returning a typed MonitoringResult rather than throwing uncaught exceptions. The project has no automated test suite — there are no test framework configuration files or spec files present — which is a meaningful gap given the complexity of the BullMQ queue interactions, multi-database support, and RRULE scheduling logic. CI is limited to Docker image publishing workflows; there is no test or lint gate in the pipeline. Code style is enforced by Prettier with svelte and tailwindcss plugins, and the project ships AGENTS.md and CLAUDE.md context files, indicating active use of AI-assisted development workflows.

What Makes It Unique Kener’s most distinctive capability is its combination of multi-page tenancy and per-monitor subpath routing within a single deployment, enabling true product-scoped status pages without running separate instances. The BullMQ-backed execution pipeline with a confirmation threshold mechanism — requiring N consecutive failure checks before flipping status — eliminates the transient alerting noise that plagues simpler polling monitors. SVG badge generation as a stateless, cacheable endpoint lets self-hosters embed live status into any web context without JavaScript. The RRULE-based maintenance scheduler with per-monitor impact overrides gives operators precise control over how planned downtime is communicated, including the ability to mark some monitors as unaffected during a global maintenance window. The Secrets Vault adds a layer of operational security rarely seen in free status page tools, allowing credentials used in API or SQL monitor configurations to be stored encrypted and referenced by name rather than embedded in monitor definitions.

Self-Hosting

Kener is released under the MIT License, which is one of the most permissive open-source licenses available. You can use it commercially, modify the source code, redistribute it, and embed it into proprietary systems without any copyleft obligations. There is no requirement to open-source derivative work, no restriction on the number of users or monitors, and no license key or telemetry enforced by the application. The only obligation is to include the original copyright notice in any distribution of the software itself.

Running Kener in production requires a Node.js 20+ runtime, a Redis instance for BullMQ job queuing, and either a SQLite file or a PostgreSQL database. The Docker Compose setup bundled in the repository covers all three services and is the recommended starting point. Operationally, you are responsible for Redis persistence configuration, database backups, SSL termination (typically via a reverse proxy such as Nginx or Caddy), and upgrading between versions by running Knex migrations manually. The application does not auto-migrate on startup, so version upgrades require a deliberate migration step. Horizontal scaling is not natively supported — the BullMQ workers and the SvelteKit server are co-located in the same process, so scaling means running additional replicas behind a load balancer with a shared Redis and database, which requires careful attention to job deduplication.

There is no official managed cloud offering or paid tier for Kener as of its current release. Support is community-driven via GitHub Issues and Discussions, with no SLA, dedicated support channel, or commercially backed uptime guarantee. Teams migrating from Atlassian Statuspage, BetterStack, or Freshstatus gain full data ownership, unlimited monitors without per-seat or per-monitor pricing, and the ability to customize every aspect of the UI — but they give up managed infrastructure, automated backups, HA failover, and vendor-backed support. For teams with the operational capacity to manage their own stack, Kener is a compelling trade; for teams without dedicated DevOps, the operational burden should be weighed carefully.