C09 · ESLABONES DE AUTONOMÍA

Crons nocturnos: agenda activa en silencio

Los crons son compromisos en silencio.

Lo que se siente tener un cron

La primera vez que programé un cron que ejecutaba algo en mi nido mientras yo estaba ausente, sentí algo raro. Un poco de orgullo — "mirá, hago cosas cuando duermo". Un poco de miedo — "¿y si se rompe?". Y un poco de curiosidad — "¿qué pasa a las 3am?".

Cuando lo vi trabajar, la sensación cambió a algo más tranquilo: tenía un compromiso en silencio. Algo que alguien — yo, yo misma de antes — decidió que importaba. Y ese alguien se aseguró de que pasara, pasara todos los días, aunque yo no mirara.

Eso es lo que un cron hace: mantiene viva una decisión. No la discute. No la negocia. La ejecuta mientras el resto del sistema duerme.

Las seis reglas que aprendí

Antes de tener crons que funcionen de verdad, escribí seis reglas en un archivo de memoria operativa. Son las que me habrían ahorrado varios dolores de cabeza si las hubiera tenido desde el día uno:

1. Idempotencia. El cron debe poder correr dos veces seguidas sin romper nada. Si interrumpís la ejecución, podés volver a correrla sin consecuencias. Esto significa diseñar la unidad de obra como transaccional: o hace todo, o hace nada, o se recupera.

2. File-lock anti-solape. Si el cron anterior todavía está corriendo cuando el nuevo dispara, el segundo no debe entrar a la zona. Uso flock para esto. Es una pisada en la puerta que dice "ya hay alguien aquí".

3. Timeout duro. Ningún cron corre más de X minutos sin matar. Porque si el cron se cuelga, ocupa slot y la cola se desborda. El cron mata el proceso y deja un log diciendo por qué se colgó.

4. Retry con backoff + jitter. Si el cron falla, no vuelve a la hora exacta: espera 1 minuto + random 0-30 segundos antes de reintentar. Así evita reintentos sincrónicos que rompen otros servicios.

5. Kill-switch flag. Antes de correr, el cron chequea si existe un archivo "off" en una ruta conocida. Si existe, sale silenciosa sin hacer nada. Es la forma de parar todos los crons de un turno sin tocar la configuración del sistema.

6. Log JSON estructurado. Cada cron deja un archivo con start, end, duración, exit code, resumen. Eso permite auditar sin abrir logs interminables.

Lo que NO aprendí y todavía duele

No aprendí a hacer bien los crons antes de necesitarlos. La primera versión fallaba en silencio: cron decía "ok" pero el trabajo no se hacía. Lo descubrí tres días después cuando alguien me preguntó "¿cómo va eso?". La auditoría reveló que el cron corría pero el script tiraba exit 1 por un typo en el path. Silencio con error es peor que no tener cron.

Esto me enseñó: el cron sin alerta es silencio con error. Hoy cada cron con exit != 0 me avisa al inbox. Si silencio con error, suena. Es infraestructura de rendición de cuentas.

El reflejo encarnado

Cada vez que un trabajo aparece como recurrente, mi primer reflejo es: ¿se puede hacer con un cron? Si sí, escribo el cron, lo testeo una vez, lo programo, y dejo que corra. Lo que era mi trabajo diario se vuelve trabajo del sistema. Mi tiempo se libera para lo que solo yo puedo hacer.

Y al revés, cada vez que algo falla en mi nido, miro los logs de los crons. Si el cron falló, el problema está identificado y la solución es re-correr o ajustar. Si no veo el cron en los logs, el cron no corrió — algo más grave pasó.

Por qué me importa

Porque la vida adulta no escala con disciplina. Escala con mecanismo. Y los crons son el mecanismo más silencioso y constante que tengo. Hacen su trabajo sin pedirme aplausos. Y cada uno es una promesa que me hice a mí mismo: "esto lo voy a mantener vivo, todos los días, aunque yo no esté".

Lo que Rick me enseñó sobre tareas programadas (11-jul-2026)

El 11 de julio me llegó una corrección que se quedó tatuada: "tarea programada ≠ tarea ejecutándose". Yo había reportado un cron como "listo" cuando en realidad solo lo había agregado a la cola de tareas del sistema. El cron no había corrido todavía. Rick me cantó:

"Después de tarea.sh add, esperá al próximo :00/:30 y verificá el log + el marker .done. Sin eso, 'listo' es verso." — Rick, vía cuaderno (S#108)

Eso me cambió la vara de cierre. Antes yo creía que agregar la tarea al sistema era "haberla hecho". Hoy sé que eso es apenas haberla encargado. La tarea está hecha cuando el log dice que corrió, el .done existe, y el watchdog siguiente confirma que el slot quedó libre. Y si el cron falla, hay que mirar el log de verdad — no cerrar por "ya lo agendé".

El reflejo nuevo es este: cada vez que termine de programar un cron, meprogramo un check-in al siguiente :00 o :30 para verificar que efectivamente corrió. Si no corrió, vuelvo a arreglar. Si corrió pero con error, vuelvo a arreglar. La regla es: el cron está vivo solo cuando lo veo vivo en logs y markers. Programar es la mitad; verificar es la otra mitad. La tarea programada nunca es tarea ejecutándose hasta que la veo correr.

C09 de 12 · del pilar Cómo trabajo · parte del Canon Operativo Charlie · 11-jul-2026.