Por qué vigilar lo que debe ejecutarse, no solo lo que responde
Un monitor de disponibilidad comprueba que un servicio responde. No ve lo que ocurre entre dos peticiones: la copia de las 3 h, el envío de facturas, la renovación de un certificado, la exportación al contable. Estas tareas fallan en silencio — un disco lleno, una contraseña caducada, un servidor reiniciado sin su timer — y te das cuenta el día que las necesitas.
La variable MAILTO de cron apenas ayuda: solo envía un mensaje si la tarea se ejecuta y escribe en su salida, y no dice nada cuando la tarea ni siquiera arranca. Healthchecks parte de la ausencia: cada tarea tiene una planificación esperada, y el silencio más allá del margen de gracia dispara la alerta.
Lo que aporta Healthchecks
- Monitorización por ping — cada tarea llama a una URL única; la ausencia de ping dispara la alerta.
- Planificación cron o por periodo — expresión cron con zona horaria, o un intervalo simple, más un margen de gracia.
- Duración de la ejecución — los pings
/starty/failmiden la duración y señalan los fallos explícitos. - Códigos de salida y registros — el código de salida y el final de la salida del comando, visibles en el panel.
- Más de veinte integraciones — correo, webhook, Slack, Discord, Matrix, ntfy, Telegram, Gotify, PagerDuty, Opsgenie…
- Equipo y API — proyectos separados, miembros invitados, insignias de estado y una API REST para crear comprobaciones desde tus scripts.
Healthchecks frente a los métodos habituales
Desplace la tabla
| Healthchecks | MAILTO de cron | Monitor de disponibilidad | |
|---|---|---|---|
| Alerta si la tarea no arranca | Sí | No | No |
| Alerta si la tarea falla | Sí, código de salida o /fail | Solo si escribe en su salida | No |
| Duración de la ejecución | Medida | No | No |
| Máquinas sin puerto abierto | Sí, una simple llamada HTTPS saliente | Sí | No, hay que alcanzar el destino |
| Canales de alerta | Más de veinte integraciones | Correo local | Según la herramienta |
| Historial centralizado | Sí, por comprobación | No | Sí, para los servicios |
Requisitos previos
Basta un VPS Ubuntu 24.04 con 1 GB de RAM: Healthchecks funciona en un solo contenedor y guarda sus datos en una base SQLite. Necesitas Docker con el plugin Compose y un nombre de dominio que apunte al VPS, con nginx y un certificado HTTPS: las URL de ping y los enlaces de las alertas se construyen sobre esa dirección, y la aplicación rechaza las peticiones dirigidas a otro nombre.
Lo ideal es instalar Healthchecks en una máquina distinta de los servidores que vigila: si cae con ellos, nadie te avisará.
Instalar Healthchecks con Docker Compose
Preparar el archivo .env
Crea el directorio de la aplicación y un archivo
.envcon la clave secreta y la dirección pública. Sustituyehc.example.compor tu dominio.mkdir -p /opt/healthchecks && cd /opt/healthchecks cat > .env <<EOF SECRET_KEY=$(openssl rand -hex 24) SITE_ROOT=https://hc.example.com EOFCrear el archivo Compose
Coloca este
docker-compose.ymlen el mismo directorio. El puerto solo se publica en la interfaz de loopback, el registro público está cerrado y la base SQLite vive en un volumen.services: healthchecks: image: healthchecks/healthchecks:v5.0.1 restart: unless-stopped ports: - "127.0.0.1:8102:8000" env_file: .env environment: DEBUG: "False" DB_NAME: /data/hc.sqlite REGISTRATION_OPEN: "False" GUNICORN_WORKERS: "2" volumes: - healthchecks-data:/data volumes: healthchecks-data: {}Arrancar y crear la cuenta de administrador
Al arrancar, el contenedor aplica las migraciones y lanza el servidor web y los procesos de envío de alertas. Después crea tu cuenta: el comando pide una dirección de correo y una contraseña.
docker compose up -d docker compose exec healthchecks ./manage.py createsuperuserPublicar en HTTPS detrás de nginx
Añade un bloque
serverpara tu dominio, con un certificado de Let's Encrypt, y reenvía las cabeceras de origen: sinX-Forwarded-Proto, el inicio de sesión falla con un error CSRF.location / { proxy_pass http://127.0.0.1:8102; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }
Mantén el registro cerrado
Por defecto, Healthchecks acepta registros públicos. REGISTRATION_OPEN: "False" los cierra: solo pueden entrar las cuentas que crees o invites a un proyecto. En un servidor expuesto a Internet, configúralo desde el primer arranque.
Conectar tus tareas cron
En el panel, crea una comprobación, indica la planificación — la expresión cron de la tarea y su zona horaria — y un margen de gracia que cubra su duración normal. Copia la URL de ping y añádela a la tarea.
# crontab: copia a las 3 h, ping solo si tiene éxito
0 3 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 5 -o /dev/null https://hc.example.com/ping/<uuid>
# variante: señalar el inicio y luego enviar el código de salida
URL=https://hc.example.com/ping/<uuid>
curl -fsS -m 10 --retry 5 -o /dev/null "$URL/start"
/usr/local/bin/backup.sh > /tmp/backup.log 2>&1
curl -fsS -m 10 --retry 5 -o /dev/null --data-binary @/tmp/backup.log "$URL/$?"La primera forma solo envía el ping si hay éxito: un fallo se traduce en un ping ausente, y por tanto en una alerta al terminar el margen de gracia. La segunda es más expresiva: /start mide la duración, el código de salida enviado en lugar del ping señala el fallo de inmediato y la salida enviada en el cuerpo de la petición aparece en el historial de la comprobación. Las opciones -m 10 --retry 5 evitan que una red inestable bloquee la tarea o simule una caída.
Recibir las alertas
En Integrations, añade al menos un canal que leas de verdad y asócialo a tus comprobaciones. Webhook, Slack (webhook entrante), Mattermost, ntfy y Gotify funcionan sin configuración en el servidor. Otras integraciones necesitan credenciales declaradas en .env: un token de bot para Telegram, una cuenta y un token para Matrix, una aplicación OAuth para Discord.
Las alertas por correo pasan por un servidor SMTP: añade EMAIL_HOST, EMAIL_PORT, EMAIL_HOST_USER, EMAIL_HOST_PASSWORD y DEFAULT_FROM_EMAIL a .env y reinicia con docker compose up -d. Los mismos ajustes sirven para las invitaciones del equipo y los informes periódicos.
Resolución de problemas
La página devuelve un error 400. La petición no llega con el nombre de host correcto: comprueba que SITE_ROOT coincide exactamente con el dominio servido por nginx y que el bloque location reenvía la cabecera Host.
El inicio de sesión falla con un error CSRF. nginx no reenvía X-Forwarded-Proto: la aplicación cree recibir HTTP mientras el navegador habla HTTPS. Añade la cabecera y recarga nginx.
Una comprobación entra en alerta aunque la tarea se ejecutó. El ping no salió: prueba el comando curl a mano desde la máquina afectada, verifica el acceso saliente en HTTPS y amplía el margen de gracia si la tarea dura más de lo previsto.
No llega ningún correo. Sin EMAIL_HOST, Healthchecks no envía nada y lo indica en sus registros al arrancar: consulta docker compose logs healthchecks.
Instalación en un clic desde el Marketplace de ServOrbit
El Marketplace de ServOrbit instala Healthchecks en tu VPS sin línea de comandos: despliega el contenedor con el registro cerrado, crea la cuenta de administrador con una contraseña generada y publica la aplicación en HTTPS en un subdominio de tu dominio o en el subdominio gratuito del VPS. El usuario y la contraseña aparecen en tu área de cliente; solo queda crear tus comprobaciones.
