Pourquoi une page de statut publique
Un outil de supervision dit à votre équipe qu'un service est en panne. Une page de statut le dit à vos utilisateurs — et c'est souvent ce qui manque pendant un incident : les clients ne savent pas si le problème vient d'eux, ouvrent des tickets en double et relancent sur les réseaux sociaux.
Kener réunit les deux rôles. Ses sondes vérifient vos services à intervalle régulier et publient l'historique de disponibilité ; quand un incident survient, vous y ajoutez des mises à jour que chacun lit au même endroit. Héberger cette page vous-même évite un abonnement à un service de statut facturé par abonné ou par page, et garde vos données de supervision chez vous.
Ce que Kener apporte
- Sondes intégrées — API et HTTP, ping, TCP, DNS, SSL, SQL et heartbeat pour les tâches planifiées.
- Incidents avec chronologie — chaque mise à jour reste visible, de la détection à la résolution.
- Maintenances planifiées — annoncées à l'avance, sans fausse alerte pendant l'intervention.
- Abonnements e-mail — vos visiteurs s'abonnent aux incidents et maintenances qui les concernent.
- Alertes d'équipe — webhook, Slack, Discord et e-mail, avec des modèles de messages.
- À votre image — logo, couleurs, thème clair ou sombre, plusieurs pages, badges et widgets.
Kener, Uptime Kuma et Gatus
Faites défiler le tableau
| Kener | Uptime Kuma | Gatus | |
|---|---|---|---|
| Rôle principal | Page de statut avec supervision intégrée | Supervision avec pages de statut en option | Supervision déclarée en YAML |
| Configuration | Interface d'administration web | Interface web | Fichier YAML |
| Abonnements e-mail des visiteurs | Oui (SMTP ou Resend) | Non | Non |
| Plusieurs pages de statut | Oui | Oui | Non, un tableau unique |
| Maintenances planifiées | Oui | Oui | Oui, déclarées en YAML |
| Stockage | SQLite, PostgreSQL ou MySQL, plus Redis | SQLite ou MariaDB | Mémoire, SQLite ou PostgreSQL |
Prérequis
Un VPS Ubuntu 24.04 avec 1 Go de RAM et 10 Go de disque, Docker et le plugin Compose installés, et un nom d'hôte qui pointe vers le VPS — par exemple status.example.com. Kener a besoin de connaître son adresse publique : la variable ORIGIN sert à sa protection contre les requêtes intersites, et toute requête d'une autre origine est refusée. Prévoyez aussi nginx et Certbot pour le HTTPS.
Installer Kener avec Docker Compose
Préparer le répertoire et la clé secrète
Créez le répertoire de l'application et un fichier
.envqui porte la clé de signature des sessions et l'adresse publique.mkdir -p /opt/kener && cd /opt/kener echo "SECRET_KEY=$(openssl rand -hex 32)" > .env echo "DOMAIN=status.example.com" >> .env chmod 600 .envÉcrire le fichier docker-compose.yml
Deux services : Redis, qui porte les files de tâches et l'ordonnanceur des sondes, et Kener, avec sa base SQLite dans un volume. Le port n'est publié que sur la boucle locale : seul nginx y accède.
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: {}Démarrer et vérifier
Lancez la pile puis interrogez le point de santé : il répond dès que l'application est prête, en général en une quinzaine de secondes.
docker compose up -d docker compose ps curl -fsS http://127.0.0.1:3000/healthcheckPublier en HTTPS avec nginx
Créez un vhost qui transmet les requêtes à Kener, puis obtenez le certificat avec
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"; } }
Créez le compte administrateur sans attendre
Kener ne crée aucun compte à l'avance : le premier visiteur de /account/signin voit le formulaire Create Admin Account et devient administrateur. Ouvrez cette page dès que le HTTPS fonctionne et créez votre compte avec un mot de passe solide. Ensuite le formulaire disparaît et toute nouvelle création est refusée.
Créer vos premières sondes
Dans l'administration, chaque moniteur correspond à une ligne de la page publique. Commencez par trois sondes : une sonde API sur la page d'accueil ou un point de santé de votre application (code HTTP attendu, délai maximal), une sonde SSL qui passe en alerte quelques jours avant l'expiration du certificat, et une sonde TCP sur le port de votre base de données si elle est joignable depuis le VPS.
Pour une tâche planifiée — sauvegarde, export, synchronisation — utilisez une sonde heartbeat : c'est la tâche qui appelle Kener à la fin de son exécution, et l'absence de signal à l'heure prévue déclenche la panne.
# at the end of your backup script
curl -fsS -m 10 https://status.example.com/ext/heartbeat/nightly-backup/YOUR_SECRETRegroupez les moniteurs par service (site, API, paiement) pour que la page reste lisible, et masquez ceux qui ne concernent que l'équipe.
Déclarer un incident et planifier une maintenance
Un incident se crée depuis l'administration : titre, moniteurs touchés, gravité, puis des mises à jour successives — « enquête en cours », « cause identifiée », « résolu ». Chaque mise à jour reste visible dans la chronologie, ce qui vaut mieux qu'un message unique modifié au fil de l'eau.
Une maintenance se planifie à l'avance avec sa fenêtre de début et de fin. Elle s'affiche sur la page avant l'intervention, et les moniteurs concernés ne comptent pas l'interruption comme une panne.
Prévenir votre équipe et vos utilisateurs
Deux circuits distincts. Pour l'équipe, les alertes se déclenchent sur l'état d'un moniteur et partent vers un webhook, Slack, Discord ou un e-mail, avec des modèles de messages réglables. Pour les visiteurs, les abonnements leur envoient les incidents et maintenances par e-mail, après confirmation de leur adresse par un code.
Les deux supposent un envoi d'e-mails configuré : ajoutez à l'environnement du service kener les variables SMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASSWORD et SMTP_SENDER, ou RESEND_API_KEY et RESEND_SENDER_EMAIL, puis relancez avec docker compose up -d. Activez ensuite les abonnements dans l'administration.
Sauvegarde et mise à jour
Toute la configuration et l'historique vivent dans la base SQLite du volume kener-data ; Redis ne porte que des files et du cache. Sauvegardez le volume après un court arrêt du service pour obtenir une copie cohérente :
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 kenerPour mettre à jour, lisez les notes de version sur la page des releases du dépôt, changez l'étiquette de l'image dans docker-compose.yml, puis lancez docker compose pull && docker compose up -d. Le conteneur met sa base à jour au démarrage : faites la sauvegarde avant.
Installation en un clic depuis le Marketplace ServOrbit
Sur un VPS ServOrbit, Kener s'installe depuis le Marketplace de votre espace client : choisissez l'adresse — un sous-domaine de l'un de vos domaines ou le sous-domaine gratuit du VPS, HTTPS compris — et cliquez sur Installer. Le script déploie Kener et Redis, génère la clé secrète, règle l'adresse publique et configure nginx. Il ne vous reste qu'à ouvrir /account/signin pour créer le compte administrateur, puis à ajouter vos sondes.
