Analizador de Expresiones Cron y constructor de crontab

Acerca de Analizador de Expresiones Cron y constructor de crontab

Esta herramienta lee una línea cron Unix estándar de cinco campos (minuto hora día-del-mes mes día-de-la-semana), la explica en lenguaje llano y calcula las próximas ejecuciones avanzando de minuto en minuto. La pestaña Constructor hace el camino inverso: eliges frecuencia, hora y días, y genera la expresión comprobándola con las mismas reglas.

Una línea cron es corta y casi nunca falla por sintaxis, sino por interpretación: poner a la vez un día del mes y un día de la semana da un O, no un Y; la misma línea se ejecuta a otra hora según la zona horaria del servidor; y las expresiones de Quartz o Spring llevan un campo de segundos de más. Aquí se repasan esas trampas con horarios concretos.

Día del mes más día de la semana es un O

Es tentador leer 0 9 1 * 1 como «a las 9:00 del día 1, solo si cae en lunes». POSIX dice lo contrario: si ninguno de los dos campos es *, basta con que el día coincida con cualquiera de ellos. Esa línea se ejecuta a las 9:00 del día 1 de cada mes y también todos los lunes a las 9:00. Si uno de los dos es *, deja de contar y el otro funciona como se espera.

El cálculo de próximas ejecuciones de esta herramienta sigue la misma regla: recuerda si cada campo era literalmente * y solo usa el O cuando ambos están restringidos. Para algo como «el primer lunes del mes», cron estándar no alcanza; lo habitual es 0 9 1-7 * * y comprobar el día de la semana dentro del script, porque entre el 1 y el 7 hay exactamente un lunes.

Zonas horarias: la misma línea, otra hora

Una expresión cron no lleva zona horaria. El cron clásico de Linux la interpreta en la hora local de la máquina, y esta herramienta muestra las ejecuciones en la zona de tu navegador. Muchas máquinas en la nube vienen en UTC, así que un 0 9 * * * pensado para las 9 de la mañana en Madrid se ejecuta a las 11:00 en verano y a las 10:00 en invierno.

En GitHub Actions el evento schedule también usa UTC por defecto. La documentación actual describe una clave opcional timezone que acepta nombres IANA como Europe/Madrid, pero la mayoría de los flujos existentes se escribieron en UTC, así que conviene leerlos así si la clave no aparece. La misma página indica que el intervalo mínimo es de cinco minutos, que en momentos de carga (como el inicio de cada hora) las ejecuciones pueden retrasarse o incluso descartarse, y que en repositorios públicos los flujos programados se desactivan tras 60 días sin actividad. Elegir un minuto raro, como 7 * * * *, evita el atasco de la hora en punto.

Horario de verano: horas que faltan y horas repetidas

En España y buena parte de Latinoamérica con cambio de hora, una noche al año se salta una hora y otra la repite. El día del adelanto no existe, por ejemplo, las 2:30; el día del retraso cierta hora ocurre dos veces. Cada programador lo resuelve a su manera: algunos cron ejecutan la tarea saltada justo después del cambio y evitan duplicar la repetida; otros simplemente la omiten. GitHub documenta que, con una timezone que tenga horario de verano, las tareas de la hora saltada pasan a la siguiente hora válida (2:30 pasa a 3:00).

Las soluciones fiables son poco vistosas: no programar entre la 1:00 y las 3:00 locales, o tener los servidores en UTC y escribir las expresiones en UTC.

Cinco campos frente a seis o siete: Quartz y Spring

Cron de Unix empieza por los minutos y tiene cinco campos. Quartz, y @Scheduled de Spring que lo sigue, añaden los segundos al principio (seis campos) y un año opcional al final (siete). Por eso 0 0 9 * * ? en Quartz equivale a 0 9 * * * en Unix.

Hay más diferencias: Quartz no admite valores a la vez en día del mes y día de la semana (uno de ellos debe ser ?), y numera los días de 1 = domingo a 7 = sábado, mientras Unix usa 0 = domingo y acepta 7 como domingo. Esta herramienta solo interpreta cinco campos, pero si pegas seis o siete te avisa de que parece Quartz o Spring y, cuando el significado se conserva, ofrece un botón para convertirla a cinco campos. No la convierte si los segundos no son 0, si fija un año o si usa sintaxis exclusiva de Quartz como L, W o #, porque el cron de cinco campos no puede expresarlo. Tampoco toca una línea de seis campos con días de la semana numéricos, ya que Quartz cuenta 1 = domingo y Spring 0 = domingo, como Unix; usa nombres como MON-FRI o quita tú los segundos y cambia ? por *, restando uno a los días numéricos si es Quartz.

Crear expresiones con el Constructor

El Constructor rellena solo los campos que exige la frecuencia elegida y deja el resto en *. Los intervalos salen como */N, que significa cada N valores contando desde el inicio del campo (0 para los minutos), no cada N minutos desde que guardaste el archivo. */7 se ejecuta en los minutos 0, 7, … 56 y vuelve al 0, de modo que el hueco entre horas es de cuatro minutos. Los divisores de 60 (5, 10, 15, 20, 30) se comportan como uno espera.

Si pegas una línea de crontab existente en el cuadro de expresión, el Constructor la descompone en sus controles, lo que ayuda a editar horarios escritos por otros.

Ejemplos

Cómo se usa

1. Pega una línea cron en la pestaña Analizador o escribe una macro como @daily.
2. Lee la descripción y las próximas ejecuciones en tu hora local.
3. Para crear una nueva, usa el Constructor y copia la línea generada.

Preguntas frecuentes