Lunes por la mañana, abres el portátil y descubres que el trabajo programado de anoche nunca se ejecutó — y que lleva tres días muerto en silencio. hermes cron list sigue mostrando el trabajo, hermes cron status no reporta ningún error, pero no hay salida, ni mensaje, ni registro que te diga qué falló. Este tipo de fallo silencioso es peor que un error: el trabajo “parece sano” mientras en realidad está muerto. El nuevo comando hermes cron doctor, fusionado el 31 de agosto, existe exactamente para este escenario: un único comando de solo lectura que revisa toda tu flota de cron de principio a fin, te dice explícitamente qué está mal y usa su código de salida para que puedas conectarlo a alertas automáticas.

Por qué “parece sano” mientras no ejecuta nada

Este comando nació de un incidente real de producción: en una flota con 60 trabajos cron, uno llevaba 5 días muerto (por un fallo del filtro de contenido) y dos trabajos watchdog no se disparaban en silencio — y ninguna de las superficies existentes (list, status, incidents) mostraba el problema de un vistazo. Los trabajos seguían en la lista, así que todo “parecía normal”; su next_run_at había vencido hacía tiempo, pero nadie lo comprobaba.

Esa es la enfermedad clásica del cron: el planificador no se queja a menos que vayas a mirar “¿cuándo debía ejecutarse, y se ejecutó de verdad?”

hermes cron doctor: un chequeo, siete comprobaciones

hermes cron doctor es un nuevo subcomando de la familia hermes cron (hermes cron [list|create|edit|pause|resume|run|remove|status|runs|doctor|tick]). Es de solo lectura — nunca modifica la configuración de los trabajos; simplemente recorre cada trabajo habilitado y reporta los hallazgos. Frente al código fuente (_cron_doctor_issues_for_job en hermes_cli/cron.py), esto es lo que comprueba:

• La última ejecución falló: cuando el last_status registrado del trabajo no es ok, reporta el last_error concreto;
• La última entrega falló: reporta last_delivery_error, por ejemplo un mensaje que nunca llegó a tu plataforma de chat;
• Trabajo habilitado sin next_run_at: un trabajo activo que no puede programar su próxima ejecución es de por sí un síntoma;
• next_run_at vencido: con un margen de gracia de 15 minutos del ticker; una marca de tiempo vencida imprime “next_run_at is Xm/h overdue — job is not firing (is the scheduler running?)” — la señal de un trabajo que no se dispara en silencio;
• Trabajo sin agente y sin script: un trabajo solo de script (no_agent: true) que no tiene script configurado;
• Problemas de salud del script: el chequeo de salud del propio script (por ejemplo, que el archivo no exista);
• workdir muerto: el workdir del trabajo ya no existe en disco.

Cualquier trabajo que toque cualquiera de estos puntos aparece en la lista — y estos rastros son exactamente el único residuo que deja un trabajo “presente en la lista pero realmente muerto”.

Así se ve la salida

Cuando todo está sano, la salida es agradablemente concisa:

✓ Cron doctor found no issues
  Checked 12 active job(s).

Cuando hay problemas, lista cada incidencia por trabajo y termina con el código de salida 1:

Cron doctor found 3 issue(s) across 2 job(s):

  cron_daily_report
    - last run failed: content filter rejected output
    - next_run_at is 26.4h overdue — job is not firing (is the scheduler running?)
  nightly_backup
    - workdir not found: /data/backups

Next: fix the listed job config, then run `hermes cron doctor` again.

Cómo usarlo: el código de salida es lo importante

Un chequeo de salud solo se justifica cuando alimenta la automatización. El código de salida es deliberadamente simple: 0 = todo sano, 1 = algo requiere acción. Así que puedes meterlo directamente en un script de monitorización:

# Chequeo diario de la flota en una línea; alerta si algo está mal
if ! hermes cron doctor; then
  hermes send -t telegram "cron fleet has a job in trouble — go check!"
fi

O simplemente ejecuta hermes cron doctor manualmente siempre que quieras una auditoría rápida. Es de solo lectura, así que siempre es seguro ejecutarlo.

Cuándo puedes usarlo

El PR #99479 se fusionó el 31 de agosto de 2026 y está solo en main — v0.20.6 (publicada el 27 de agosto) aún no tiene este subcomando. Actualiza a la última versión de main para usarlo ya, o espera a la próxima release. La documentación oficial (la guía de cron y la referencia de la CLI) ya lo documenta.

Los trabajos programados solo cumplen su función cuando se ejecutan de forma fiable sin que nadie los vigile, y la fiabilidad empieza por saber que realmente se ejecutan. hermes cron doctor convierte ese “saber” en un solo comando. Para una automatización más completa, consulta nuestra guía completa de automatización con cron y la guía de monitorización y comprobaciones previas de cron; si tus trabajos siguen fallando en silencio a las 3 de la madrugada, la guía de ajuste del loop-watchdog del gateway también merece la pena. Referencia del comando: hermes cron.