Analizar una expresión cron _

¿Qué es una expresión cron?

Una expresión cron es una cadena de programación compacta que indica a un planificador de tareas exactamente cuándo ejecutar un trabajo. El formato nació en 1975 dentro del daemon cron de Unix V7 y apenas ha cambiado desde entonces — la misma gramática de cinco campos aparece hoy en Kubernetes CronJobs, AWS EventBridge, flujos de trabajo de GitHub Actions, Google Cloud Scheduler, GitLab CI, pipelines de Jenkins y el binario crontab que se distribuye con cada distribución Linux. La gramática condensa mucho significado en unos trece caracteres, razón por la que un analizador que la convierte a lenguaje natural es la diferencia entre un despliegue confiado y un rollback a las 3 de la madrugada.

¿Cómo funciona una expresión cron?

Una expresión cron estándar tiene cinco campos separados por espacios que definen conjuntamente una programación repetitiva. El motor compara el reloj actual con la expresión cada minuto y ejecuta el trabajo cuando los cinco campos coinciden. Los campos, de izquierda a derecha:

1. Minuto (0–59). En qué minuto de la hora se ejecuta el trabajo. 0 significa a la hora en punto, 30 a la media hora, */5 cada cinco minutos (00, 05, 10, ...) y 15,45 a cuarto y a menos cuarto.
2. Hora (0–23). Hora del día en formato 24h. 0 es medianoche, 9 son las 9:00, 17 son las 17:00. Los rangos (9-17 para horario laboral) y los valores de paso (*/2 para cada dos horas) funcionan igual que para los minutos.
3. Día del mes (1–31). Qué día del calendario ejecutar. 1 es el primer día del mes, * todos los días, 1,15 el día 1 y el 15. Ten cuidado con 31 — omite silenciosamente los meses que no tienen 31 días.
4. Mes (1–12 o JAN–DEC). En qué meses ejecutar. * es cada mes, 1,7 enero y julio, 1-3 solo el primer trimestre. Los nombres de mes de tres letras no distinguen entre mayúsculas y minúsculas en la mayoría de implementaciones.
5. Día de la semana (0–7, donde 0 y 7 equivalen a domingo). Restringe la ejecución a días de la semana concretos. 1-5 es de lunes a viernes, 0,6 el fin de semana, MON-FRI funciona en la mayoría de analizadores. Cuando se fijan valores concretos en día del mes y día de la semana, el cron clásico dispara si se cumple cualquiera de los dos (OR lógico), lo que sorprende a todo el mundo sin excepción.

¿Por qué usar un analizador de expresiones cron?

• Detecta la lectura errónea silenciosa antes del despliegue. La expresión `0 2 */3 * *` se dispara a las 2:00 cada tercer día, no cada tres minutos — pégala aquí y lo verás en lenguaje natural antes de que llegue a producción.
• La mayoría de planificadores en la nube corren en UTC por defecto. Previsualizar las próximas diez ejecuciones en tu zona local pone de manifiesto el desfase de una hora por el horario de verano antes de que despierte a alguien a las 3 de la madrugada.
• Los atajos como `@daily`, `@weekly` y `@monthly` son cómodos pero ambiguos. El analizador muestra la forma subyacente de cinco campos para que sepas exactamente qué se ha programado.
• El constructor campo a campo te permite componer una programación columna a columna y ver la descripción en lenguaje natural actualizarse en tiempo real — mucho más rápido que releer la página de manual de cron por décima vez.

¿Dónde se usan las expresiones cron?

La sintaxis cron aparece en cualquier lugar donde un trabajo deba repetirse según un reloj. Tres de las superficies más comunes, con el problema exacto por el que cada una es famosa:

• Programas de copia de seguridad. La entrada clásica de `crontab -e` que vuelca una base de datos en S3 a las 2:00 de la madrugada, o rota un archivo `pg_dump` el día 1 de cada mes. Una línea como `0 2 * * * /usr/local/bin/backup.sh` ha corrido en más servidores Linux que cualquier otra línea cron de la historia. Acierta en el minuto y la hora, redirige stderr a algún lugar duradero, y habrás reemplazado una lista de comprobación manual por un script de ejecutar-y-olvidar.
• Disparadores `schedule` de GitHub Actions. La clave `on.schedule.cron` en `.github/workflows/*.yml` acepta cron estándar de cinco campos, pero el trabajo siempre corre en UTC y GitHub omitirá silenciosamente una ejecución si la cola de runners está ocupada. Patrón habitual: `cron: '0 9 * * 1-5'` para enviar un resumen de lunes a viernes a las 9:00 UTC. Previsualízalo aquí en tu zona local para no prometer un resumen a las 9:00 en Madrid que en realidad llega a las 10:00 en verano.
• AWS EventBridge Scheduler. Las expresiones cron de EventBridge llevan un sexto campo para el año y exigen `?` en lugar de `*` en el campo de día del mes o el de día de la semana — `cron(0 9 ? * MON-FRI *)` es la traducción EventBridge del clásico cron de días laborables a las 9:00. Se usa para invocaciones programadas de Lambda, ejecuciones de tareas ECS y arranques de máquinas de estado Step Functions; la incompatibilidad con la sintaxis cron clásica es la principal fuente de errores `ValidationException` en los despliegues de CloudFormation.

¿Cómo es una expresión cron real?

Toma 0 9 * * 1-5 — se dispara a las 9:00, todos los días laborables. Leyendo los campos de izquierda a derecha: 0 es el minuto cero de la hora, 9 son las 9:00 en formato 24h, * en día del mes significa todos los días del calendario, * en mes significa cada mes y 1-5 en día de la semana restringe el disparo de lunes a viernes (donde 1 = lunes en la numeración cron estándar). Pégalo en el campo de arriba y el analizador confirma A las 09:00, de lunes a viernes con las diez próximas fechas en la zona IANA que selecciones. La misma intención en sintaxis de AWS EventBridge es cron(0 9 ? * MON-FRI *) — obsérvese el campo de año al final y el ? donde cron estándar usaría *. La misma intención como expresión Quartz (seis campos con segundos iniciales) es 0 0 9 ? * MON-FRI. Tres plataformas distintas, tres formas distintas, una única programación.

Las expresiones cron son implacables en exactamente un sentido: un error tipográfico te da una programación sintácticamente válida que se dispara a la hora equivocada, sin ningún error que detectar en la revisión del código. Leer `0 0 1 * *` y saber que se ejecuta a medianoche el día 1 de cada mes, no el 1 de enero, requiere práctica. El analizador de arriba convierte esa práctica en una comprobación de diez segundos — pega la expresión, lee el inglés, revisa las diez próximas ejecuciones en tu zona local y despliega el YAML sabiendo que la línea cron hace realmente lo que dice el mensaje del commit.

¿Cuál es la diferencia entre cron de 5 y 6 campos?

El cron de cinco campos es la gramática Unix clásica con resolución de un minuto. El de seis añade una columna inicial de segundos para programación por debajo del minuto — usado por Quartz y el @Scheduled de Spring. AWS EventBridge también usa seis campos, pero su columna extra es un año al final, no segundos.

¿Qué significan @hourly, @daily y @weekly?

Apodos de Vixie-cron introducidos en 1987. @hourly = 0 * * * *, @daily = 0 0 * * *, @weekly = 0 0 * * 0, @monthly = 0 0 1 * *, @yearly = 0 0 1 1 *. @reboot se ejecuta una vez al arrancar. GitHub Actions y EventBridge rechazan estos alias.

¿El domingo es el día 0 o el día 7 en cron?

Ambos, en el cron Vixie clásico — se aceptan 0 y 7 para que los rangos como 5-7 se lean de forma natural como viernes-domingo. El lunes siempre es 1, el sábado siempre es 6. Quartz y AWS EventBridge usan otra convención: 1-7 con domingo como 1. Consulta la documentación de la plataforma antes de dar por supuesto nada.

¿Cómo gestiona cron el horario de verano?

Depende de la zona horaria del motor. En UTC (el predeterminado en EventBridge, Kubernetes y GitHub Actions) el horario de verano no existe. En una zona DST local, el cron Vixie clásico omite trabajos durante el avance de primavera y los ejecuta dos veces durante el retroceso de otoño; los temporizadores de systemd se disparan exactamente una vez.