Análisis de expresiones cron y predicción de ejecuciones

Funciones

• Toda la sintaxis habitual: asterisco, valor único, rangos a-b, listas a,b,c y pasos /n sobre asteriscos o rangos
• Se aceptan los nombres de mes y de día de la semana (JAN-DEC, SUN-SAT)
• Explicación campo a campo y resumen de una línea, como «cada 15 minutos de 09:00 a 17:00 de lunes a viernes»
• Enumera las próximas 1-50 ejecuciones, con el día de la semana de cada una
• También enumera las ejecuciones anteriores: la búsqueda hacia atrás baja desde la unidad mayor y resuelve bien el 29 de febrero, los minutos `*/5` y las programaciones semanales
• Una nota relativa en cada instante («dentro de 2 horas 13 minutos» / «hace 3 días») en el idioma de la interfaz
• Se puede fijar un instante de referencia (vacío = ahora) para consultas retrospectivas
• Aplica la regla clásica de O entre día del mes y día de la semana (semántica de Vixie cron)
• Entiende las macros @daily, @hourly, @weekly, @monthly y @yearly
• Las programaciones imposibles se rechazan de entrada, nombrando los campos que no pueden coincidir
• Las ejecuciones se pueden mostrar en hora local o en UTC, porque los cron de servidor suelen correr en UTC

Cómo se usa

1. Pega una expresión cron de 5 campos en el cuadro
2. Elige el idioma de la descripción, cuántas ejecuciones listar y la zona horaria; activa las anteriores y fija un instante de referencia si lo necesitas
3. Haz clic en «Ejecutar» (o pulsa Ctrl/⌘ + Enter)
4. Copia el resultado o corrige la expresión con ayuda del desglose

Preguntas frecuentes

¿Por qué se ha rechazado mi expresión de 6 campos?

Un campo de segundos al principio es la convención de Quartz y Spring; el cron clásico tiene cinco campos. Leer una expresión de 6 campos como si tuviera 5 desplaza cada campo una posición, de modo que las ejecuciones que obtienes son de una programación completamente distinta; esta herramienta la rechaza y te pide que quites el campo de segundos en lugar de adivinar.

¿Qué pasa cuando se rellenan a la vez el día del mes y el día de la semana?

El cron clásico (Vixie) los trata como una O: «0 0 1 * 1» se dispara el día 1 del mes o cualquier lunes. Solo cuando uno de los dos es un asterisco pasa a ser una Y. Muchas implementaciones se equivocan en esto; esta herramienta sigue a Vixie.

¿En qué zona horaria están las ejecuciones?

En la que elijas, y por defecto la hora local. Los contenedores y servidores suelen ejecutar cron en UTC, mientras que la hora local es más fácil de comprobar a mano, así que se ofrecen las dos. Al cambiar, todas las horas listadas se desplazan, y el día de la semana con ellas.

¿Por qué dice que la expresión nunca se disparará?

Por ejemplo, «0 0 31 2 *»: febrero no tiene 31 en ningún año, así que nunca se ejecuta. La herramienta comprueba si la combinación de día y mes existe en algún año. Además hay un límite de búsqueda de cuatro años (los huecos entre bisiestos pueden llegar a ocho); pasado el límite informa de que no ha encontrado nada, en vez de buscar sin fin.

¿Cómo se calculan las ejecuciones anteriores? ¿Por qué no basta con dar la vuelta a las próximas?

Porque el cron es asimétrico en el eje del tiempo, así que la lógica de salto hacia delante falla al invertirla. Hacia delante, un mes que no coincide salta al día 1 del mes siguiente; hacia atrás hay que saltar al último día del mes anterior a las 23:59. Los minutos `*/5` deben retroceder hasta un minuto divisible por 5, y `0 0 * * 0` hasta el domingo anterior. Cada dirección cae en un sitio distinto, así que la búsqueda hacia atrás recorre de mayor a menor (mes → día → hora → minuto) como una implementación aparte, simétrica a la de ida. La ventana también es de cuatro años hacia atrás: la anterior de `0 0 29 2 *` llega hasta el último 29 de febrero real, y lo dice claramente si no hay ninguno en cuatro años.

¿Qué pasa con las ejecuciones en los días del cambio de hora?

Siguen las reglas reales de la zona elegida (la hora local es la zona de esta máquina). ⚠️ El día que empieza el horario de verano hay horas de reloj que no existen (las 02:30 del 2026-03-08 en Nueva York, por ejemplo), así que una programación como `30 2 * * *` se salta ese día en lugar de desplazarse a las 01:30 o a las 03:30: una hora desplazada parece normal pero está una hora desviada. El día que termina, algunas horas ocurren dos veces (las 01:30 del 2026-11-01 en Nueva York) y ambas cuentan como ejecuciones válidas. Nada de esto es trabajo extra de la herramienta: la aritmética del calendario se delega en la base de datos de zonas horarias del sistema (los métodos locales de `Date`). Las implementaciones que suman y restan desfases a mano fallan esos días por una hora, y solo esos días.