Cuando un cron con IA falla en silencio, no reviso los logs al azar. Ejecuto seis comprobaciones en orden: el intérprete de Python, el mensaje completo del error, si el sitio responde a curl, si el cron está realmente apagado, si la tarea guarda checkpoints y si el contexto del modelo está saturado. Cada una me costó un incidente real. Estas son las lecciones.
Corro 58 crons con agentes en una Raspberry Pi 5 con Hermes y DeepSeek. El patrón que más plata me costó no es el que explota con un traceback: es el que termina con exit 0 habiendo hecho todo mal. El sistema no te avisa. Te avisa la factura, y ya hablé de eso en lo que cuesta correr agentes IA en una RPi.
¿Por qué un cron de IA puede fallar sin que nadie se entere?
Hay tres razones concretas. La primera: cron descarta stdout y stderr salvo que los redirijas a un archivo. La segunda: muchos scripts terminan con exit 0 aunque el trabajo interno haya fallado, y si nadie lee el log, el fallo no existe. La tercera es la que más cuesta interiorizar: un agente LLM no falla como un programa normal. No tira stack trace. Te dice "tarea completada" y se va a dormir, aunque el resultado sea basura.
Por eso no sirve esperar el error. Hay que ir a buscarlo con un orden fijo.
Comprobación 1: ¿usa el intérprete de Python correcto?
En julio tuve un ModuleNotFoundError en un cron que no se iba con nada. Corría pip3 install del módulo, el import funcionaba en la terminal, y el cron seguía fallando igual. El culpable: el cron no usa el python del sistema. Usa la venv de Hermes, en ~/.hermes/hermes-agent/venv/, y ahí el módulo nunca existió.
/home/luigy/.hermes/hermes-agent/venv/bin/pip3 install <modulo>
/home/luigy/.hermes/hermes-agent/venv/bin/python3 -c "import <modulo>"La regla que quedó escrita: instalá con el pip de la misma venv que ejecuta el cron y verificá importando con ese mismo intérprete. Instalar en el python del sistema es tirar el tiempo, porque el cron jamás lo va a mirar. Después estandarizamos todos los crons con wrappers de ruta absoluta. La ambigüedad desapareció.
Comprobación 2: ¿leíste el mensaje completo del error?
El 3 de agosto, openrouter apareció como unhealthy en todos los crons a la vez. Mi primer reflejo fue "revocaron la key". La reemplacé. La key era válida, y perdí la mañana persiguiendo un problema que no existía.
El mensaje real decía: 402 payment/credit error, "can only afford 11055". Traducción: quedaban 11 centavos de saldo y el request pedía más tokens de los que el saldo permitía. No era seguridad. Era billing. El complemento de este caso, con dos bugs de una línea que parecen otra cosa, está en 3 bugs invisibles que rompieron mis agentes.
La lección: cuando un proveedor devuelve 402 con "can only afford N tokens", es saldo agotado, no key muerta. Verificá el saldo y la key en /auth/key antes de tocar credenciales. Y mientras tanto pineá ese provider a uno con saldo, porque el fallback automático te va a seguir pegando contra el mismo muro.
Comprobación 3: ¿el sitio que monitoreás responde a curl?
El 11 de agosto, un script de keepalive llevaba once fallos seguidos. Once de once. curl 000 contra app.polymarket.com. 000 significa una sola cosa: no hubo respuesta HTTP. Mi script estaba bien. El problema era el objetivo.
Polymarket es una SPA con bot-detection y geo-blocking. A curl jamás le va a responder 200, y ningún retry lo va a arreglar. La regla que aplico desde entonces: solo monitorear con curl los sitios que responden a curl. Para SPAs se usa un navegador real o directamente se las saca del health check. El 000 casi nunca es tu script. Es el sitio diciéndote "no te conozco".
Comprobación 4: ¿el cron está realmente desactivado?
El caso más humillante: rpi-health, un cron de salud del sistema, acumuló 152 ejecuciones estando "pausado". Lo había pausado por dentro del sistema. El cron job seguía disparándose cada dos horas, tranquilo, durante semanas. El motivo: la pausa interna (state.json) no elimina el cron job. La historia completa de esa deuda técnica está en mis 58 cron jobs casi colapsan.
Para apagar un loop de verdad hay que hacer tres cosas: eliminar el cron job, comentar la entrada en loops.yaml y sacarlo de chains.yaml. Las tres. Si dejás una, el loop vuelve. Un loop "pausado" que sigue corriendo es el fallo silencioso perfecto: consume tokens, no produce nada y nadie lo mira.
Comprobación 5: ¿tu tarea larga guarda checkpoints?
Todo cron de más de diez pasos debería guardar progreso incremental en un archivo .progress. Si falla a mitad de camino, el reintento retoma desde el último checkpoint. Si no, retoma desde cero y el fallo cuesta el doble.
Suena obvio y no lo era. Mi pipeline de extracción de 707 documentos se cayó a mitad de proceso, y cada reintento empezaba de nuevo desde el principio. Con checkpoint, un fallo pasa de "perdí una hora" a "retomo donde estaba". No es elegante. Es un archivo de texto con el paso actual. Funciona.
Comprobación 6: ¿el contexto del agente está saturado?
Cuando el contexto acumulado supera el 80% del límite del modelo, los agentes no fallan con un error. Degradan: empiezan a repetirse, pierden el hilo, generan basura con total confianza. Es el fallo más caro de todos porque parece que todo anda bien. En cómo detecto loops infinitos en agentes cuento las señales de comportamiento; acá va la regla de presupuesto.
El fix: comprimir los pasos previos en resúmenes de una o dos líneas por paso. Se preservan las decisiones clave y se descarta el output redundante. Ojo con el exceso de celo: no hay que comprimir proactivamente. La compresión se dispara ante señales de fallo, como tool calls repetidos, tokens de incertidumbre ("no estoy seguro", "quizás") o progreso estancado durante tres ciclos. Si el agente está sano, se lo deja tranquilo.
El orden importa
Las comprobaciones van de la más barata a la más cara de diagnosticar. El intérprete se verifica en diez segundos. El contexto saturado requiere leer el historial completo del agente. Si empezás por el final, vas a perder horas. Si empezás por la uno, la mayoría de los casos se resuelven ahí.
Implementar todo esto no lleva infraestructura. Son unas cincuenta líneas de Python repartidas en tres scripts y un watchdog que avisa por Telegram cuando un exit code no es cero. No hace falta Datadog ni LangGraph. En mis números, los fallos silenciosos pasaron de dos o tres por semana a casi cero, y la factura de tokens bajó. No tengo un porcentaje mágico para venderte. Tengo un sistema que avisa.
Conclusión
El patrón común de estos seis casos es uno solo: el sistema no te avisa cuando algo anda mal. Te avisa cuando ya pagaste. Las comprobaciones no eliminan los fallos, pero convierten el diagnóstico de "¿qué pasó? no sé" en diez minutos de chequeo ordenado.
Este artículo refleja mi experiencia real con 58 crons de Hermes corriendo en una Raspberry Pi 5. Los seis casos tienen fecha y el fix correspondiente está en producción desde julio y agosto de 2026.
Preguntas frecuentes
¿Por qué mi cron falla sin que vea ningún error?
Porque cron descarta la salida estándar salvo que la redirijas, y porque muchos scripts terminan con exit 0 aunque el trabajo interno haya fallado. Redirigí stdout y stderr a un archivo de log y monitoreá el exit code de cada ejecución, no solo los mensajes de error.
¿Qué significa el error 402 "can only afford N tokens"?
Que el saldo del proveedor no alcanza para el request que pediste. No es una key revocada ni un problema de tu código. Verificá el saldo y la key en /auth/key del proveedor antes de reemplazar credenciales, y pineá temporalmente el servicio a un provider con saldo.
¿Por qué curl devuelve 000 contra un sitio?
000 significa que no hubo respuesta HTTP. En sitios con JavaScript pesado y bot-detection, curl no recibe nada y ningún reintento lo arregla. Solo monitorees con curl los sitios que responden a curl; para el resto usá un navegador real o sacalos del health check.
¿pip3 install no arregla el ModuleNotFoundError de mi cron?
Lo más probable es que el cron no use el python del sistema sino una venv propia. Instalá el módulo con el pip de esa venv, usando la ruta absoluta, y verificá con el intérprete de la misma venv. Instalar en el python del sistema no toca el entorno del cron.
¿Cada cuánto debería revisar los logs de mis crons?
Con 58 crons, revisar todo a mano no escala. Un watchdog diario que te alerte por Telegram ante exit codes no cero, más una revisión manual semanal de los logs importantes, alcanza. El objetivo es que el sistema te avise a vos, no al revés.