Automatización con horario

Hasta ahora tus automatizaciones reaccionaban a eventos. Este tipo es distinto: cosas que pasan a una hora determinada — un reporte cada lunes, un respaldo cada noche.

Cron es el lenguaje clásico para expresarlo: cinco campos separados por espacios — minuto, hora, día del mes, mes y día de la semana. El asterisco significa «cualquier valor». Ejemplo: 0 9 * 1 se lee «minuto 0, hora 9, cualquier día del mes, cualquier mes, día de la semana 1» — es decir, todos los lunes a las 09:00.

Tu sistema operativo ya trae programadores gratuitos: cron en sistemas tipo Unix, launchd en macOS, Task Scheduler en Windows. Corren mientras tu máquina esté encendida.

Para que corra en la nube, GitHub Actions acepta un cron en el YAML del repositorio. Sus reglas reales:

• El intervalo mínimo es de 5 minutos.
• El cron se interpreta en UTC por defecto (existe un campo opcional timezone con nombres IANA).
• En repositorios públicos, los workflows programados se desactivan tras 60 días sin actividad.
• En horas pico la ejecución puede retrasarse.
• Añade workflow_dispatch para poder lanzarlo a mano y probar sin esperar al horario.

Cinco campos, cuatro gotchas: con eso programás cualquier tarea recurrente.

Dos hábitos de profesional:

• Vigila los fallos silenciosos. Una tarea programada que falla no grita: simplemente deja de producir resultados. Si tu backup automático lleva tres meses fallando y nadie configuró un aviso, nadie lo sabe. Configura una notificación de fallo (o un latido periódico) y verifica de vez en cuando que el resultado real existe. «Ningún aviso» no significa «todo bien»: un proceso muerto tampoco avisa.
• Diseña de forma idempotente. Entre retrasos, reintentos y ejecuciones manuales con workflow_dispatch, la misma tarea puede correr dos veces. Correr dos veces no debe duplicar nada: verifica si el registro ya existe antes de insertarlo.