Cron no reporta fallos. Un job se cae, el calendario sigue adelante, y te enteras días después por un cliente. Cronitorex espera un ping de cada ejecución y te alerta en 60 segundos cuando uno no llega.
Cada ejecución reporta run al arrancar, y luego complete o fail al terminar. Dos llamadas adicionales en tu crontab son suficientes. Sin agente, sin daemon, ninguna biblioteca que instalar.
A partir de esos pings, Cronitorex construye una línea de tiempo por job: duraciones, códigos de salida, historial de fallos. Una ejecución que arranca y nunca termina también cuenta como un fallo.
*/5 * * * * root cronitorex ping db-backup run; /opt/backup.sh && cronitorex ping db-backup complete || cronitorex ping db-backup fail
Un servidor caído no envía ningún ping fail. Cronitorex conoce el intervalo esperado de cada job y espera un período de gracia adicional para absorber las variaciones normales. Cuando esa ventana se cierra sin un ping, recibes una alerta de ejecución perdida.
Ambos valores los defines tú por monitor. Un backup nocturno con 15 minutos de gracia se comporta distinto de un job de sincronización que corre cada 5 minutos con 60 segundos de gracia.
El cliente cronitorex.sh envuelve tu comando: envía run, ejecuta el job, mide la duración, captura el código de salida y las últimas líneas de stderr, y termina con complete o fail. Cambias una palabra en el crontab, no tu script.
¿Ya tienes un crontab completo? El comando discover lo lee y crea un monitor para cada job que encuentra, con el horario tomado directamente de la expresión cron.
# envuelve cualquier job: captura código de salida, duración y stderr cronitorex.sh run db-backup -- /opt/backup.sh # importa tu crontab existente como monitores cronitorex.sh discover /etc/crontab
Sí. Cualquier cosa que pueda enviar una solicitud HTTP puede hacer ping: timers de systemd, CronJobs de Kubernetes, tareas de Airflow, GitHub Actions, Programador de tareas de Windows. Cronitorex solo ve los pings, no el programador que hay detrás.
Cada ping es un evento: run, complete, fail o skip. Un job que envía run y complete una vez por hora produce cerca de 1.440 eventos al mes, así que los 50.000 eventos del plan Free alcanzan para docenas de jobs.
La API empieza a devolver HTTP 402 y los nuevos pings dejan de aceptarse hasta que se reinicia el mes o subes de plan. No se elimina nada; el panel y tu historial siguen disponibles todo el tiempo.
Regístrate, consigue una API key, pega el curl en tu cron. Eso es todo.