Healthchecks 4.3 frente a cron: latidos, alertas y salida
Guía para vigilar backups y tareas programadas con pings HTTP, gracia, avisos y restauración. Qué guarda la base y qué prueba cada alerta.
Un cron que falla a las 02:07 puede seguir pareciendo sano hasta que alguien pide la copia. Healthchecks 4.3 recibe pings HTTP de tareas programadas y avisa cuando el latido llega tarde, falla o tarda más de lo pactado. Para una pyme con backups, importaciones y reportes nocturnos, esta guía muestra qué medir, quién recibe el aviso y cómo probar la salida.
Dónde aparece el cron mudo
El problema operativo aparece cuando la tarea programada escribe un log local y nadie lo mira. Un backup termina, una importación queda a medias o un reporte no se genera; al día siguiente, soporte encuentra un archivo viejo con fecha correcta en el nombre y contenido incompleto. El antagonista es el cron mudo: ejecuta, falla y no deja una señal que gerencia pueda leer. La documentación de Healthchecks.io describe un modelo simple: cada tarea envía un ping a una URL única, y el servicio levanta alerta si el ping no llega a tiempo. La release v4.3, publicada el 14 de julio de 2026, sumó mejoras de avisos, texto de notificaciones, duración de caída y Argon2 como hasher por defecto para contraseñas y tokens. Una cifra baja la discusión a tierra: el repositorio abierto healthchecks/healthchecks tenía 10.220 estrellas y licencia BSD-3-Clause al momento de esta corrida. El dato global viene de Stack Overflow 2025: PostgreSQL aparece con 55,6% entre bases usadas. Esa combinación ayuda a elegir una pila conocida para registrar tareas, estados y avisos sin comprar una plataforma cerrada por cada job.
Cómo funciona por dentro Healthchecks guarda checks, pings, estado, canales y reglas de tiempo.
La tarea programada envía una señal de inicio, éxito, falla o código de salida. El servicio calcula si llegó dentro del período y la gracia configurada. PostgreSQL puede guardar checks, proyectos, usuarios, pings y auditoría en una instalación propia. El canal de aviso entrega el estado a correo, ntfy, Gotify, Matrix, Telegram u otro webhook. 1. Sistemas crea un check por tarea: backup, importación, antivirus o reporte. 2. La aplicación asigna una URL por UUID o por ping key y slug. 3. El script envía /start al iniciar y éxito o /fail al terminar. 4. Healthchecks valida horario, período, gracia y cuerpo recibido. 5. PostgreSQL guarda evento, duración, estado, proyecto y usuario. 6. El canal de aviso notifica al responsable correcto. 7. El backup restaura base, configuración y una alerta de prueba. La Pinging API acepta HEAD, GET o POST y permite reportar éxito, inicio, falla, log o código de salida. También documenta un límite de 100 kB para cuerpo de ping y advierte contra pings de más de cinco veces por minuto por check. El dato sensible es la URL de ping: quien la conoce puede simular una tarea sana.
Qué se instala o configura primero
La pila mínima usa Healthchecks 4.3, PostgreSQL, proxy HTTPS, correo o ntfy, usuarios por proyecto, backup diario y tablero de tareas. La configuración self-hosted permite definir PING_ENDPOINT, base de datos, límites de cuerpo y canales. El primer entregable verificable son seis checks: backup de base, backup de archivos, importación CSV, reporte diario, cola de facturación y limpieza de temporales. Con dólar oficial vendedor a ARS 1520, el costo de una instancia chica de USD 25 a USD 60 mensuales queda entre ARS 38.000 y ARS 91.200, según disco, dominio y respaldo. Un piloto de 18 a 30 horas técnicas a USD 30/h queda entre USD 540 y USD 900, es decir entre ARS 820.800 y ARS 1.368.000. Incluye instalación, seis checks, dos canales, documentación de horarios, backup y restauración. Quedan fuera operación de guardia, corrección de scripts viejos y mensajería paga. El acta de cierre debe mostrar una falla provocada y una recuperación registrada. UMSA puede aplicar este patrón cuando una organización ya tiene cron, systemd timers o tareas de aplicación y necesita saber si terminaron. La primera decisión técnica es escribir el horario esperado con tolerancia: cada hora más cinco minutos, o cada día hábil a las 07:10 con diez minutos de gracia.
Dónde se rompe y cómo probarlo
El primer riesgo es una URL de ping filtrada. La señal aparece cuando un check marca éxito desde una IP que no ejecuta la tarea. La prueba rota el ping key, revisa logs y limita salida desde el servidor real. El segundo riesgo es usar slug autoaprovisionado sin gobierno. La señal aparece cuando nacen checks con nombres parecidos y nadie sabe cuál corresponde al job activo. La prueba crea un catálogo de tareas y desactiva cualquier slug que no tenga dueño. El tercer riesgo es alerta sin responsable. La notificación llega a un grupo general y queda leída por todos. La prueba falla un job de ensayo, confirma destinatario, mensaje, enlace y tiempo de recuperación. Después se restaura Healthchecks en otra instancia y se repite el mismo ping. Una tarea programada deja de ser invisible cuando alguien puede mostrar su último latido, su falla y su recuperación.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.