Mi cron llevaba 17 días muerto y mi dashboard decía que todo estaba bien

El domingo a las 21:05 mi sistema se auto-examinó y dictaminó: cero problemas críticos. El informe decía que mi vault estaba sano, que los enlaces internos estaban bien, que el 96,8% de los archivos cumplían las reglas. Todo perfecto.

Una hora y cuarto después, a las 22:22, otro de mis agentes escribió la nota diaria del 30 de agosto. Y en esa nota dejó constancia, por escrito, de que el job de la mañana no había generado ese día la nota. No era la primera vez. Era la número 17 desde el 13 de agosto.

El mismo día. El sistema me dijo "todo bien" y, una hora después, me dejó por escrito que llevaba 17 días roto. Ninguno de los dos mentía. Los dos tenían razón, y eso es lo que me tiene escribiendo esto.

El sistema que se vigila solo

Llevo meses construyendo una infraestructura que no debería necesitarme. Decenas de crons en una Raspberry Pi, agentes que se auto-reparan, un health check semanal que arregla lo que encuentra. La regla que me impuse es dura: tolerancia cero con los bugs que no se reparan solos.

Resulta que tuve un bug sin reparar durante 18 días y ningún dashboard, ningún agente, ningún health check me avisó.

Lo más incómodo de todo: el fallo no era invisible. Estaba documentado.

Cómo funcionaba la rutina, y dónde se rompió

Mi segundo cerebro (un vault de Obsidian con miles de notas) tiene una rutina diaria en dos turnos. A las 8:00, un cron llamado obsidian-morning debe crear la nota del día. A las 22:20, otro llamado obsidian-nightly consolida el vault, audita duplicados y, si la nota del día no existe, la crea él.

Fíjate en la belleza del diseño: redundancia. Si el de la mañana falla, el de la noche lo cubre. Nunca te quedas sin nota. El sistema siempre funciona.

Lo que pasó de verdad:

• El 13 de agosto, por la mañana, nadie generó la nota. No sé qué pasó ese día exactamente, los logs no lo dicen.
• A partir de ahí, 17 de las 18 mañanas siguientes, el job de la mañana no hizo su trabajo. El patrón quedó anotado cada noche: "morning job no la generó, 11ª ocurrencia", "12ª", hasta la "17ª ocurrencia del patrón Aug 13-30".
• Cuando fui a mirar el cron, esto es lo que encontré: creado el 21 de agosto, última ejecución el 23 a las 8:02 con estado "ok", y pausado a las 9:26 de ese mismo día. Llevaba muerto más de una semana, y la nota seguía apareciendo cada noche como si nada.

Ahí está el fallo de diseño, y es más profundo de lo que parece. Cuando dos procesos hacen el mismo trabajo, puedes matar uno y el resultado final se ve idéntico. La nota existía. Las estadísticas cuadraban. El health check validaba que la nota estuviera bien formada, no que la hubiera creado el proceso correcto. Validaba el artefacto, no el proceso. Por eso decía "0 críticos": el artefacto estaba perfecto. El proceso llevaba muerto ocho días.

Y el colmo: cada noche, el nightly escribía en la propia nota que el morning había fallado. El fallo estaba documentado 17 veces en el archivo más visible del sistema. Un archivo que nadie lee, porque lo genera una máquina para que lo lea otra máquina. Nadie lo leyó. Yo incluido.

Lo que aprendí, y que aplica a tus backups también

Esto no es un problema raro de un friki con demasiados crons. Si tienes un backup nocturno, un pipeline de CI o un informe automático que nadie abre, tienes el mismo problema. Tres lecciones:

1. Monitorea procesos, no outputs. Que el resultado exista no significa que el proceso correcto lo haya hecho. Un backup que "se hace" cada noche no es un backup: es un directorio con archivos. La única prueba real es restaurar. Aquí la única prueba real era mirar la hora de creación del archivo, no su existencia.

2. La redundancia esconde la degradación. La doble generación de la nota convirtió un fallo diario en algo indistinguible del funcionamiento normal. La redundancia sin telemetría no es resiliencia: es un escondite. Si quieres que la copia de seguridad te avise cuando el original muere, alguien tiene que comparar los dos.

3. Si un agente anota un patrón de fallo, alguien tiene que leer esa anotación. El nightly avisaba cada noche. El problema no era que no avisara, era que nadie escuchaba. Los logs que nadie lee son ruido, y el ruido te impide oír las alarmas de verdad.

La pregunta incómoda

Me quedé con una pregunta: si esto llevaba 17 días y nadie lo vio, ¿qué más lleva semanas muerto mientras su gemelo lo tapa? Fui a mirar. En el mismo día encontré tres más:

• Un monitor que falla cada mañana porque le falta un módulo de Python (cloudscraper) que nunca se instaló.
• Un cron que ejecuta un script (run-loop-graph.sh system-health) que no existe en el sistema.
• Tailscale deslogueado desde hace días, con el acceso remoto "funcionando" de todas formas gracias a un túnel de respaldo.

Tres fallos más, todos invisibles, todos con el mismo patrón: el output final se veía bien, así que nadie miró el proceso. No son fallos exóticos. Son la norma cuando automatizas cosas y vigilas resultados en vez de procesos.