--- title: "Página de estado self-hosted: alternativas a Instatus" description: "Compara alternativas self-hosted a Instatus y Statuspage y despliega Gatus con Docker en Ubuntu 24.04, con comprobaciones, alertas y ventanas de mantenimiento." category: "Páginas de Estado e Incidentes" language: es source: https://cubepath.com/es/docs/páginas-de-estado-e-incidentes/alternativa-self-hosted-de-pagina-de-estado updated: 2026-09-25 --- # Página de estado self-hosted: alternativas a Instatus Una página de estado autoalojada te permite informar de caídas y mantenimientos sin pagar por servicios como Instatus o Atlassian Statuspage y sin depender de sus límites de componentes o suscriptores. En esta guía compararás las opciones open source más usadas y después desplegarás Gatus con Docker en Ubuntu 24.04: una página de estado que además comprueba tus servicios, guarda el historial, envía alertas y respeta ventanas de mantenimiento. ## Requisitos previos - Un servidor con Ubuntu 24.04 LTS y 1 GB de RAM, por ejemplo un VPS de CubePath, **distinto** de los servidores que vas a monitorizar. - Un usuario no root con privilegios `sudo`. - Docker Engine y el plugin Docker Compose instalados desde el repositorio oficial de Docker. - Un subdominio como `status.your_domain` con un registro A apuntando al servidor. - Los puertos 22, 80 y 443 abiertos en UFW. > Importante: si la página de estado vive en el mismo servidor o en la misma red que los servicios que monitoriza, se caerá con ellos. Colócala en otra ubicación o en otro proveedor. ## Comparativa de soluciones | Solución | Tipo | Monitoriza por sí sola | Gestión de incidentes | Dónde se ejecuta | |----------|------|------------------------|-----------------------|------------------| | **Gatus** | Aplicación Go, configurada en YAML | Sí (HTTP, TCP, DNS, ICMP, certificados) | Estado automático según las comprobaciones | Docker o binario, SQLite o PostgreSQL | | **Uptime Kuma** | Aplicación Node.js con interfaz web | Sí | Incidentes y mantenimientos desde la interfaz | Docker o Node.js | | **Upptime** | GitHub Actions + GitHub Pages | Sí, desde los runners de GitHub | Incidentes como issues de GitHub | GitHub, sin servidor propio | | **cState** | Sitio estático con Hugo | No | Incidentes como archivos Markdown | Cualquier hosting estático | Cómo elegir: - **Gatus** si quieres que el estado se calcule solo a partir de comprobaciones reales y prefieres configurarlo todo como código en un archivo versionable. - **Uptime Kuma** si prefieres una interfaz web para añadir monitores y publicar incidentes a mano. - **Upptime** o **cState** si no quieres mantener ningún servidor: la página se aloja en GitHub Pages u otro hosting estático. El resto de la guía despliega Gatus. ## Paso 1: Crear la configuración de Gatus Gatus lee toda su configuración de un archivo YAML: qué endpoints comprobar, con qué condiciones y a quién avisar. Crea un directorio para el proyecto: ```bash sudo mkdir -p /opt/gatus cd /opt/gatus ``` Crea el archivo de configuración: ```bash sudo nano /opt/gatus/config.yaml ``` Este ejemplo comprueba una web, el endpoint de salud de una API, un puerto de base de datos y la caducidad del certificado TLS. Sustituye los dominios por los tuyos: ```yaml storage: type: sqlite path: /data/gatus.db ui: title: Estado de los servicios header: Estado de los servicios link: https://your_domain alerting: email: from: alertas@your_domain username: alertas@your_domain password: ${SMTP_PASSWORD} host: smtp.your_domain port: 587 to: sre@your_domain default-alert: failure-threshold: 3 success-threshold: 2 send-on-resolved: true endpoints: - name: Web group: Servicios web url: https://your_domain interval: 1m conditions: - "[STATUS] == 200" - "[RESPONSE_TIME] < 2000" alerts: - type: email - name: API group: Servicios web url: https://api.your_domain/health interval: 1m conditions: - "[STATUS] == 200" - "[BODY].status == ok" alerts: - type: email - name: Base de datos group: Infraestructura url: tcp://db.your_domain:5432 interval: 1m conditions: - "[CONNECTED] == true" alerts: - type: email - name: Certificado TLS group: Infraestructura url: https://your_domain interval: 1h conditions: - "[CERTIFICATE_EXPIRATION] > 336h" alerts: - type: email ``` Algunos detalles: - Cada endpoint aparece en la página dentro de su `group`, y su estado es verde solo si se cumplen todas las `conditions`. - `[BODY].status == ok` lee el campo `status` de una respuesta JSON; adáptalo a lo que devuelva tu endpoint de salud. - `failure-threshold: 3` evita avisar por un fallo aislado: la alerta salta tras tres comprobaciones fallidas seguidas. - `${SMTP_PASSWORD}` se sustituye por la variable de entorno del mismo nombre, así la contraseña no queda en el YAML. Guarda la contraseña SMTP en un archivo de entorno que solo pueda leer root. Sustituye `your_smtp_password` por la real: ```bash echo "SMTP_PASSWORD=your_smtp_password" | sudo tee /opt/gatus/.env > /dev/null sudo chmod 600 /opt/gatus/.env ``` ## Paso 2: Arrancar Gatus con Docker Compose Crea el archivo de Compose: ```bash sudo nano /opt/gatus/compose.yaml ``` ```yaml services: gatus: image: twinproduction/gatus:latest restart: unless-stopped env_file: .env ports: - "127.0.0.1:8080:8080" volumes: - ./config.yaml:/config/config.yaml:ro - gatus-data:/data volumes: gatus-data: ``` El puerto se publica solo en `127.0.0.1` porque Nginx se encargará del acceso desde fuera con HTTPS. Para producción, sustituye `latest` por una versión concreta de la imagen y actualízala a propósito. Arranca el contenedor: ```bash sudo docker compose up -d ``` Comprueba los logs. Gatus valida la configuración al arrancar y se detiene con un mensaje claro si hay un error de sintaxis: ```bash sudo docker compose logs --tail 20 gatus ``` Consulta el endpoint de salud del propio Gatus: ```bash curl -s http://127.0.0.1:8080/health ``` ```output {"status":"UP"} ``` ## Paso 3: Publicar la página con Nginx y HTTPS Instala Nginx y Certbot: ```bash sudo apt install nginx certbot python3-certbot-nginx ``` Crea el sitio: ```bash sudo nano /etc/nginx/sites-available/gatus ``` ```nginx server { listen 80; server_name status.your_domain; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } ``` Actívalo, comprueba la sintaxis, abre el firewall y solicita el certificado: ```bash sudo ln -s /etc/nginx/sites-available/gatus /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx sudo ufw allow 'Nginx Full' sudo certbot --nginx -d status.your_domain ``` Abre `https://status.your_domain`. Verás tus endpoints agrupados, con una barra de historial por cada uno que se va llenando con cada comprobación. ## Paso 4: Probar las alertas Antes de fiarte de las alertas, provoca un fallo controlado. Añade temporalmente al final de `endpoints` en `config.yaml` un endpoint que no existe: ```yaml - name: Prueba de alerta group: Pruebas url: https://noexiste.your_domain interval: 30s conditions: - "[STATUS] == 200" alerts: - type: email ``` Gatus detecta los cambios en el archivo de configuración y lo recarga sin reiniciar. Si no ves el endpoint nuevo en la página, reinicia el contenedor: ```bash sudo docker compose restart gatus ``` Tras tres comprobaciones fallidas (unos 90 segundos) debe llegar el correo de alerta. Si no llega, busca errores SMTP en los logs: ```bash sudo docker compose logs gatus | grep -i alert ``` Elimina el endpoint de prueba cuando hayas confirmado que funciona. Gatus admite muchos otros canales además del correo, como Slack, Discord, Telegram, Microsoft Teams, PagerDuty o un webhook genérico. Se configuran en el mismo bloque `alerting`. ## Paso 5: Configurar ventanas de mantenimiento Durante un mantenimiento planificado no quieres recibir alertas por caídas esperadas. Añade un bloque `maintenance` en la raíz de `config.yaml`, por ejemplo para los domingos de 02:00 a 04:00 en hora de Madrid: ```yaml maintenance: start: "02:00" duration: 2h timezone: "Europe/Madrid" every: [Sunday] ``` Durante esa ventana Gatus sigue comprobando los endpoints y registrando su estado, pero no envía alertas. Si omites `every`, la ventana se aplica todos los días. ## Paso 6: Consultar el estado desde la API Gatus expone el estado de todos los endpoints en JSON, útil para integrarlo en tu panel o en otras herramientas: ```bash curl -s https://status.your_domain/api/v1/endpoints/statuses | python3 -m json.tool | head -n 20 ``` ```output [ { "name": "Web", "group": "Servicios web", "key": "servicios-web_web", "results": [ { "status": 200, "hostname": "your_domain", ... ``` ## Solución de problemas **El contenedor se reinicia en bucle.** La configuración tiene un error. `sudo docker compose logs gatus` muestra la línea del YAML o la condición que no es válida. **Un endpoint aparece en rojo pero el servicio funciona.** Mira el detalle del endpoint en la página: Gatus muestra qué condición ha fallado. Lo habitual es un código 301 en lugar de 200 (ajusta la URL o la condición) o un campo JSON con otro nombre en `[BODY]`. **Los cambios en `config.yaml` no se aplican.** Algunos editores reemplazan el archivo en lugar de modificarlo y el montaje de un solo archivo en Docker sigue apuntando al antiguo. Reinicia con `sudo docker compose restart gatus`. ## Conclusión Has comparado las principales alternativas self-hosted a Instatus y desplegado Gatus con Docker, HTTPS, alertas por correo probadas y una ventana de mantenimiento semanal. Como siguientes pasos, puedes guardar `config.yaml` en un repositorio Git para revisar los cambios, añadir un canal de alertas de chat para el equipo de guardia y cambiar el almacenamiento a PostgreSQL si vas a monitorizar muchos endpoints.