Why a public status page
A monitoring tool tells your team that a service is down. A status page tells your users — and that is often what is missing during an incident: customers do not know whether the problem is on their side, open duplicate tickets and chase you on social media.
Kener combines both roles. Its checks test your services at regular intervals and publish the uptime history; when an incident happens, you add updates that everyone reads in one place. Hosting this page yourself avoids a status-page subscription billed per subscriber or per page, and keeps your monitoring data with you.
What Kener brings
- Built-in checks — API and HTTP, ping, TCP, DNS, SSL, SQL and heartbeat for scheduled jobs.
- Incidents with a timeline — every update stays visible, from detection to resolution.
- Scheduled maintenance — announced in advance, with no false alert during the work.
- Email subscriptions — visitors subscribe to the incidents and maintenance that concern them.
- Team alerts — webhook, Slack, Discord and email, with message templates.
- Your brand — logo, colours, light or dark theme, several pages, badges and widgets.
Kener, Uptime Kuma and Gatus
Scroll the table
| Kener | Uptime Kuma | Gatus | |
|---|---|---|---|
| Main role | Status page with built-in monitoring | Monitoring with optional status pages | Monitoring declared in YAML |
| Configuration | Web admin interface | Web interface | YAML file |
| Visitor email subscriptions | Yes (SMTP or Resend) | No | No |
| Several status pages | Yes | Yes | No, a single dashboard |
| Scheduled maintenance | Yes | Yes | Yes, declared in YAML |
| Storage | SQLite, PostgreSQL or MySQL, plus Redis | SQLite or MariaDB | Memory, SQLite or PostgreSQL |
Prerequisites
An Ubuntu 24.04 VPS with 1 GB of RAM and 10 GB of disk, Docker and the Compose plugin installed, and a hostname pointing to the VPS — for example status.example.com. Kener needs to know its public address: the ORIGIN variable drives its cross-site request protection, and any request from another origin is rejected. Also plan nginx and Certbot for HTTPS.
Install Kener with Docker Compose
Prepare the directory and the secret key
Create the application directory and a
.envfile holding the session signing key and the public address.mkdir -p /opt/kener && cd /opt/kener echo "SECRET_KEY=$(openssl rand -hex 32)" > .env echo "DOMAIN=status.example.com" >> .env chmod 600 .envWrite the docker-compose.yml file
Two services: Redis, which holds the job queues and the check scheduler, and Kener, with its SQLite database in a volume. The port is published on the loopback only: only nginx reaches it.
services: redis: image: redis:7.4-alpine restart: unless-stopped command: ["redis-server", "--appendonly", "yes"] volumes: - kener-redis:/data healthcheck: test: ["CMD", "redis-cli", "ping"] interval: 10s timeout: 5s retries: 10 kener: image: rajnandan1/kener:4.1.10 restart: unless-stopped depends_on: redis: condition: service_healthy ports: - "127.0.0.1:3000:3000" environment: KENER_SECRET_KEY: ${SECRET_KEY} ORIGIN: https://${DOMAIN} REDIS_URL: redis://redis:6379 DATABASE_URL: sqlite://./database/kener.sqlite.db volumes: - kener-data:/app/database volumes: kener-data: {} kener-redis: {}Start and check
Start the stack, then query the health endpoint: it answers as soon as the application is ready, usually within about fifteen seconds.
docker compose up -d docker compose ps curl -fsS http://127.0.0.1:3000/healthcheckPublish over HTTPS with nginx
Create a vhost that forwards requests to Kener, then get the certificate with
certbot --nginx -d status.example.com.server { listen 443 ssl http2; server_name status.example.com; # ssl_certificate / ssl_certificate_key: added by Certbot location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } }
Create the admin account straight away
Kener creates no account in advance: the first visitor of /account/signin sees the Create Admin Account form and becomes administrator. Open this page as soon as HTTPS works and create your account with a strong password. After that the form disappears and any new creation is refused.
Create your first checks
In the admin area, each monitor is one line on the public page. Start with three checks: an API check on your application's home page or health endpoint (expected HTTP code, maximum delay), an SSL check that turns to alert a few days before the certificate expires, and a TCP check on your database port if it is reachable from the VPS.
For a scheduled job — backup, export, synchronisation — use a heartbeat check: the job calls Kener when it finishes, and no signal at the expected time triggers the outage.
# at the end of your backup script
curl -fsS -m 10 https://status.example.com/ext/heartbeat/nightly-backup/YOUR_SECRETGroup monitors by service (website, API, payment) so the page stays readable, and hide those that only concern the team.
Declare an incident and schedule maintenance
An incident is created from the admin area: title, affected monitors, severity, then successive updates — « investigating », « identified », « resolved ». Each update stays visible in the timeline, which beats a single message edited along the way.
Maintenance is scheduled in advance with its start and end window. It shows on the page before the work, and the affected monitors do not count the interruption as an outage.
Notify your team and your users
Two separate channels. For the team, alerts fire on a monitor's state and go to a webhook, Slack, Discord or an email, with adjustable message templates. For visitors, subscriptions send them incidents and maintenance by email, after they confirm their address with a code.
Both require email sending to be configured: add the SMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASSWORD and SMTP_SENDER variables to the kener service environment, or RESEND_API_KEY and RESEND_SENDER_EMAIL, then restart with docker compose up -d. Then enable subscriptions in the admin area.
Backup and updates
All the configuration and history live in the SQLite database of the kener-data volume; Redis only holds queues and cache. Back up the volume after briefly stopping the service to get a consistent copy:
cd /opt/kener
docker compose stop kener
docker run --rm -v kener_kener-data:/data -v "$PWD":/backup alpine \
tar czf /backup/kener-$(date +%F).tar.gz -C /data .
docker compose start kenerTo update, read the release notes on the repository's releases page, change the image tag in docker-compose.yml, then run docker compose pull && docker compose up -d. The container upgrades its database on start: take the backup first.
One-click install from the ServOrbit Marketplace
On a ServOrbit VPS, Kener installs from the Marketplace in your client area: choose the address — a subdomain of one of your domains or the VPS's free subdomain, HTTPS included — and click Install. The script deploys Kener and Redis, generates the secret key, sets the public address and configures nginx. All that is left is to open /account/signin to create the admin account, then add your checks.
