Por qué una página de estado pública
Una herramienta de monitorización avisa a tu equipo de que un servicio está caído. Una página de estado se lo dice a tus usuarios — y eso es lo que suele faltar durante un incidente: los clientes no saben si el problema viene de su lado, abren tickets duplicados y te reclaman en las redes sociales.
Kener reúne ambos papeles. Sus sondas comprueban tus servicios a intervalos regulares y publican el historial de disponibilidad; cuando ocurre un incidente, añades actualizaciones que todos leen en el mismo sitio. Alojar esta página tú mismo evita una suscripción a un servicio de páginas de estado facturado por suscriptor o por página, y mantiene tus datos de monitorización contigo.
Lo que aporta Kener
- Sondas integradas — API y HTTP, ping, TCP, DNS, SSL, SQL y heartbeat para tareas programadas.
- Incidentes con cronología — cada actualización queda visible, de la detección a la resolución.
- Mantenimientos programados — anunciados por adelantado, sin falsas alertas durante la intervención.
- Suscripciones por correo — los visitantes se suscriben a los incidentes y mantenimientos que les afectan.
- Alertas del equipo — webhook, Slack, Discord y correo, con plantillas de mensajes.
- A tu imagen — logotipo, colores, tema claro u oscuro, varias páginas, insignias y widgets.
Kener, Uptime Kuma y Gatus
Desplace la tabla
| Kener | Uptime Kuma | Gatus | |
|---|---|---|---|
| Función principal | Página de estado con monitorización integrada | Monitorización con páginas de estado opcionales | Monitorización declarada en YAML |
| Configuración | Interfaz de administración web | Interfaz web | Archivo YAML |
| Suscripciones de visitantes por correo | Sí (SMTP o Resend) | No | No |
| Varias páginas de estado | Sí | Sí | No, un único panel |
| Mantenimientos programados | Sí | Sí | Sí, declarados en YAML |
| Almacenamiento | SQLite, PostgreSQL o MySQL, más Redis | SQLite o MariaDB | Memoria, SQLite o PostgreSQL |
Requisitos previos
Un VPS Ubuntu 24.04 con 1 GB de RAM y 10 GB de disco, Docker y el plugin Compose instalados, y un nombre de host que apunte al VPS — por ejemplo status.example.com. Kener necesita conocer su dirección pública: la variable ORIGIN rige su protección contra peticiones entre sitios, y toda petición de otro origen se rechaza. Prevé también nginx y Certbot para el HTTPS.
Instalar Kener con Docker Compose
Preparar el directorio y la clave secreta
Crea el directorio de la aplicación y un archivo
.envcon la clave de firma de las sesiones y la dirección pública.mkdir -p /opt/kener && cd /opt/kener echo "SECRET_KEY=$(openssl rand -hex 32)" > .env echo "DOMAIN=status.example.com" >> .env chmod 600 .envEscribir el archivo docker-compose.yml
Dos servicios: Redis, que lleva las colas de tareas y el planificador de las sondas, y Kener, con su base SQLite en un volumen. El puerto solo se publica en la interfaz local: solo nginx accede a él.
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: {}Arrancar y comprobar
Arranca la pila y consulta el punto de salud: responde en cuanto la aplicación está lista, normalmente en unos quince segundos.
docker compose up -d docker compose ps curl -fsS http://127.0.0.1:3000/healthcheckPublicar en HTTPS con nginx
Crea un vhost que reenvíe las peticiones a Kener y obtén el certificado con
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"; } }
Crea la cuenta de administrador sin esperar
Kener no crea ninguna cuenta por adelantado: el primer visitante de /account/signin ve el formulario Create Admin Account y pasa a ser administrador. Abre esta página en cuanto funcione el HTTPS y crea tu cuenta con una contraseña robusta. Después el formulario desaparece y se rechaza cualquier nueva creación.
Crear tus primeras sondas
En la administración, cada monitor corresponde a una línea de la página pública. Empieza con tres sondas: una sonda API sobre la página de inicio o un punto de salud de tu aplicación (código HTTP esperado, tiempo máximo), una sonda SSL que alerta unos días antes de que caduque el certificado, y una sonda TCP sobre el puerto de tu base de datos si es accesible desde el VPS.
Para una tarea programada — copia de seguridad, exportación, sincronización — usa una sonda heartbeat: es la tarea la que llama a Kener al terminar, y la ausencia de señal a la hora prevista dispara la caída.
# at the end of your backup script
curl -fsS -m 10 https://status.example.com/ext/heartbeat/nightly-backup/YOUR_SECRETAgrupa los monitores por servicio (sitio, API, pagos) para que la página siga siendo legible, y oculta los que solo interesan al equipo.
Declarar un incidente y programar un mantenimiento
Un incidente se crea desde la administración: título, monitores afectados, gravedad y después actualizaciones sucesivas — « investigando », « causa identificada », « resuelto ». Cada actualización queda visible en la cronología, lo que es mejor que un único mensaje editado sobre la marcha.
Un mantenimiento se programa por adelantado con su ventana de inicio y fin. Aparece en la página antes de la intervención, y los monitores afectados no cuentan la interrupción como una caída.
Avisar a tu equipo y a tus usuarios
Dos circuitos distintos. Para el equipo, las alertas se disparan según el estado de un monitor y se envían a un webhook, Slack, Discord o un correo, con plantillas de mensajes ajustables. Para los visitantes, las suscripciones les envían los incidentes y mantenimientos por correo, tras confirmar su dirección con un código.
Ambos requieren el envío de correo configurado: añade al entorno del servicio kener las variables SMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASSWORD y SMTP_SENDER, o RESEND_API_KEY y RESEND_SENDER_EMAIL, y reinicia con docker compose up -d. Activa después las suscripciones en la administración.
Copia de seguridad y actualización
Toda la configuración y el historial viven en la base SQLite del volumen kener-data; Redis solo lleva colas y caché. Copia el volumen tras una breve parada del servicio para obtener una copia coherente:
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 kenerPara actualizar, lee las notas de versión en la página de releases del repositorio, cambia la etiqueta de la imagen en docker-compose.yml y ejecuta docker compose pull && docker compose up -d. El contenedor actualiza su base al arrancar: haz la copia antes.
Instalación en un clic desde el Marketplace de ServOrbit
En un VPS de ServOrbit, Kener se instala desde el Marketplace de tu área de cliente: elige la dirección — un subdominio de uno de tus dominios o el subdominio gratuito del VPS, con HTTPS incluido — y haz clic en Instalar. El script despliega Kener y Redis, genera la clave secreta, ajusta la dirección pública y configura nginx. Solo queda abrir /account/signin para crear la cuenta de administrador y añadir tus sondas.
