Cómo alojar Healthchecks por tu cuenta en 2026: pings de cron, alertas y copias de seguridad de la base de datos

Alojar Healthchecks por tu cuenta se vuelve interesante con el primer redeploy, no con el primer docker run. Si los trabajos de cron envían pings a una URL interna o los workers de correo no están en ejecución, Docker puede seguir informando de que el proceso está perfectamente saludable. El despliegue siguiente se organiza en torno a un comportamiento observable: enviar pings de inicio, éxito y error desde un trabajo de prueba, omitir después un ping programado y recibir la alerta de trabajo perdido.

El propósito de Healthchecks es claro: monitorización dead-man para trabajos de cron y tareas en segundo plano. Esta descripción indica qué debe permanecer público, qué debería seguir siendo privado y qué debe poder reconstruir una copia de seguridad.

Haz una copia de seguridad del estado que Healthchecks no puede recrear

El contenedor estándar de Healthchecks no requiere ningún montaje de datos de aplicación. Aun así, su conjunto de recuperación está claramente definido: la base de datos de la aplicación y la configuración de notificaciones. No crees un volumen vacío solo para que el despliegue parezca stateful; conserva la referencia exacta de la imagen y la configuración revisada.

Reconstruye Healthchecks en un host vacío y ejecuta la transacción de aceptación. La recuperación es correcta cuando vuelven los checks, las programaciones, las integraciones y las claves de ping, y un ping omitido intencionadamente genera la alerta esperada. Cualquier base de datos conectada o servicio de colaboración debe seguir su propio plan de copias de seguridad coherente con la aplicación, mientras que el contenedor web reemplazable se recrea a partir del código. La guía de despliegue de Git a producción describe ese límite reproducible.

Conserva una suma de comprobación o un digest de la imagen conocida como válida y vuelve a probar después de las actualizaciones. En un servicio stateless, una reconstrucción correcta es la prueba de restauración; para el estado externo, el runbook de Healthchecks debe enlazar con el propietario y el procedimiento de recuperación independientes.

Crea un contenedor de Healthchecks reemplazable

Usa un comando que exponga todas las decisiones importantes. Esta configuración base vincula Healthchecks al loopback del host, añade los montajes de datos conocidos y proporciona el primer ajuste obligatorio. Añade la configuración de conexión revisada para Postgres y un servicio de entrega de correo operativo para las alertas de producción; utiliza nombres privados para los servicios privados.

docker run -d \
  --name healthchecks \
  --restart unless-stopped \
  -p 127.0.0.1:8000:8000 \
  -e SECRET_KEY=replace-with-a-long-random-value \
  -e SITE_ROOT=https://app.example.com \
  -e ALLOWED_HOSTS=app.example.com \
  -e DB=postgres \
  -e DB_HOST=postgres.internal \
  -e DB_NAME=healthchecks \
  -e DB_USER=healthchecks \
  -e DB_PASSWORD=replace-with-a-strong-database-password \
  healthchecks/healthchecks:latest

Sustituye las tags flotantes por una versión probada o un digest. Después del arranque, inspecciona docker logs --tail 200 healthchecks y confirma que el proceso escucha en el puerto 8000. A continuación, ejecuta la acción de aceptación de Healthchecks; la respuesta de la página principal no puede demostrar que todo el escenario funciona: envía pings de inicio, éxito y error desde un trabajo de prueba, omite después un ping programado y recibe la alerta de trabajo perdido.

De qué depende Healthchecks

Dibuja tres límites alrededor de Healthchecks: la entrada al puerto 8000, el estado duradero y los requisitos auxiliares. El contenedor es reemplazable, pero los otros dos elementos necesitan propietarios explícitos. El contrato de red de Healthchecks incluye Postgres y un servicio de entrega de correo operativo para las alertas de producción. Mantén los endpoints privados en DNS interno, permite únicamente las llamadas salientes necesarias y proporciona a Healthchecks una credencial de servicio con permisos limitados.

El diagrama está completo cuando un cliente limpio puede enviar pings de inicio, éxito y error desde un trabajo de prueba, omitir después un ping programado y recibir la alerta de trabajo perdido. Captura datos de tiempos y recursos relativos al número de checks, los periodos de gracia, la distribución de notificaciones, la entrega de correo y las escrituras en la base de datos. Si la transacción falla, el primer límite que no se comporte como está documentado indica si debes investigar el enrutamiento, la capacidad local o un servicio auxiliar.

Enruta Healthchecks sin falsear HTTPS

Elige el hostname final de Healthchecks antes de que los usuarios guarden callbacks o ajustes de cliente; después, configura SITE_ROOT y ALLOWED_HOSTS con la dirección HTTPS externa. La ruta de la plataforma debe terminar TLS una sola vez y apuntar al puerto privado 8000.

Ejecuta la transacción de aceptación desde el exterior. Si el cliente nunca llega a Healthchecks, utiliza la lista de comprobación de validación de SSL para revisar el DNS y el certificado. Si la solicitud llega a Healthchecks, pero los trabajos de cron envían pings a una URL interna o los workers de correo no están en ejecución, deja de cambiar las redirecciones del proxy e inspecciona el límite específico de la aplicación.

Evidencias que debes recopilar antes de poner Healthchecks en producción

Crea una fixture pequeña y desechable de Healthchecks y consérvala para cada release. La fixture debe probar el flujo real: enviar pings de inicio, éxito y error desde un trabajo de prueba, omitir después un ping programado y recibir la alerta de trabajo perdido. Registra el digest de la imagen, el hostname externo, la dirección de la dependencia y el resultado esperado para que otro operador pueda repetir la prueba más adelante sin tener que interpretar esta guía.

Ejecuta la fixture tres veces. Primero, utiliza el despliegue recién creado. Segundo, sustituye el contenedor sin tocar el estado duradero. Tercero, restaura la copia de seguridad en un entorno vacío. La tercera ejecución solo es correcta cuando vuelven los checks, las programaciones, las integraciones y las claves de ping, y un ping omitido intencionadamente genera la alerta esperada. Durante cada ejecución, captura la latencia y el uso de recursos relacionados con el número de checks, los periodos de gracia, la distribución de notificaciones, la entrega de correo y las escrituras en la base de datos; esto se convierte en la línea base de las alertas, en lugar de un porcentaje de CPU arbitrario.

Por último, prueba deliberadamente la ruta negativa: deniega temporalmente a la identidad de prueba el acceso a Postgres y al servicio de entrega de correo operativo para las alertas de producción. Confirma que Healthchecks falla de forma visible sin corromper el estado, restablece la condición correcta y repite la transacción correcta. Un registro del release que contenga esos cuatro resultados ofrece evidencias más sólidas que las capturas de un dashboard o una respuesta puntual de curl.

Simulacros de fallo para Healthchecks

Observa el trabajo que realiza Healthchecks: número de checks, periodos de gracia, distribución de notificaciones, entrega de correo y escrituras en la base de datos. Establece límites con margen para ese trabajo y evita una liveness probe que compita con él. La comprobación del operador también debería intentar enviar pings de inicio, éxito y error desde un trabajo de prueba, omitir después un ping programado y recibir la alerta de trabajo perdido según una programación.

Para las actualizaciones, recuerda que las migraciones de la aplicación y la configuración de los workers deben actualizarse conjuntamente para que la página web no oculte una entrega de alertas defectuosa. Despliega la candidata sobre una copia restaurada y repite la prueba conocida. Si los trabajos de cron envían pings a una URL interna o los workers de correo no están en ejecución, utiliza los logs de runtime y la solicitud de red real para descubrir qué supuesto ha cambiado.

Elige el límite de confianza de Healthchecks

Cierra la ventana de bootstrap en cuanto exista el primer administrador de confianza. La trampa concreta de Healthchecks consiste en utilizar un secreto generado que cambia en cada reinicio; el límite más seguro es usar una SECRET_KEY estable, restringir la pertenencia a los proyectos y tratar las URL de ping como credenciales.

Genera SECRET_KEY una sola vez, mantenla fuera de Git y consérvala junto con el manifiesto de recuperación, ya que cambiarla puede invalidar el estado cifrado o firmado de la aplicación. La red privada debe transportar las credenciales de las dependencias, y los roles dentro de Healthchecks deben conceder la acción útil mínima. Mantén los cuerpos de las solicitudes sensibles y las respuestas de los proveedores fuera de los logs habituales.

Un despliegue de Dockup sigue necesitando una prueba de aceptación de Healthchecks

Dockup puede gestionar las piezas reemplazables de la plataforma: enrutar el tráfico al puerto 8000, emitir el dominio y el certificado, inyectar secretos, conectar el almacenamiento persistente y enlazar Healthchecks con servicios gestionados o conectados de forma privada. Puede hacerlo en la infraestructura de Dockup o en un servidor que conectes.

El trabajo de aceptación de Healthchecks sigue siendo explícito. Después del despliegue con un clic, configura SITE_ROOT y ALLOWED_HOSTS con la dirección HTTPS externa, conecta y prueba Postgres y el servicio de entrega de correo operativo para las alertas de producción, y ejecuta este escenario: envía pings de inicio, éxito y error desde un trabajo de prueba, omite después un ping programado y recibe la alerta de trabajo perdido. Esta división es intencionada: Dockup elimina la configuración repetitiva de la infraestructura sin fingir que los roles de la aplicación, las credenciales de los proveedores o la política de restauración se eligen por sí solos.

Preguntas frecuentes

¿Qué necesita Healthchecks para un despliegue en producción?

Enruta el contenedor de Healthchecks a través de un único origen HTTPS en el puerto 8000. El requisito de red auxiliar es Postgres y un servicio de entrega de correo operativo para las alertas de producción. No consideres que Healthchecks está listo hasta que puedas enviar pings de inicio, éxito y error desde un trabajo de prueba, omitir después un ping programado y recibir la alerta de trabajo perdido.

¿Qué datos de Healthchecks deben incluirse en una copia de seguridad?

La imagen estándar de Healthchecks no requiere ningún montaje de datos de aplicación. Conserva la configuración de despliegue y realiza copias de seguridad del estado conectado por separado; la recuperación es correcta cuando vuelven los checks, las programaciones, las integraciones y las claves de ping, y un ping omitido intencionadamente genera la alerta esperada.

¿Healthchecks necesita HTTPS detrás de un reverse proxy?

Usa HTTPS para el origen público de Healthchecks y mantén el puerto 8000 en la ruta interna. Aplica correctamente el ajuste de Healthchecks: configura SITE_ROOT y ALLOWED_HOSTS con la dirección HTTPS externa. En Healthchecks, HTTPS protege las credenciales o el contenido de los usuarios durante el tránsito y mantiene coherente el comportamiento del cliente sensible al origen.

¿Cómo debe probarse una actualización de Healthchecks?

Restaura el estado actual de Healthchecks en un despliegue aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención, porque las migraciones de la aplicación y la configuración de los workers deben actualizarse conjuntamente para que la página web no oculte una entrega de alertas defectuosa. Conserva la imagen anterior de Healthchecks hasta comprender los límites de migración de datos y rollback.