Analizador Cron & Validador Crontab

Analizador Cron & Validador Crontab

Analice expresiones cron en descripciones legibles. Inspeccione marcas de tiempo en múltiples zonas horarias, valide sintaxis crontab y proyecte próximas ejecuciones.

Escenarios preconfigurados
Tokens analizados5/5
MIN
*/5
HOUR
*
DOM
*
MON
*
DOW
*
Cadencia de programaciónEvery 5 minutes past every hour.
Variables de orden superiorSin solapamiento
Tiempo estimado de ejecución1 minutos
Diagrama visual de ejecuciónEn memoria
LEX5 tokensASTMáscara de bits (Bitmask)POSIXCleanRUNSafeSLOT10 salidas
Cronograma de próximas ejecuciones(10 occurrences)
N.ºHora local proyectadaDía de la semanaCuenta atrás / RelativoIntervalo con jitterMarca de tiempo UTC (ISO 8601)
1Nov 03, 2026, 03:20Tuein 3m 16sexact2026-11-03T03:20:00.565Z
2Nov 03, 2026, 03:25Tuein 8m 16sexact2026-11-03T03:25:00.565Z
3Nov 03, 2026, 03:30Tuein 13m 16sexact2026-11-03T03:30:00.565Z
4Nov 03, 2026, 03:35Tuein 18m 16sexact2026-11-03T03:35:00.565Z
5Nov 03, 2026, 03:40Tuein 23m 16sexact2026-11-03T03:40:00.565Z
6Nov 03, 2026, 03:45Tuein 28m 16sexact2026-11-03T03:45:00.565Z
7Nov 03, 2026, 03:50Tuein 33m 16sexact2026-11-03T03:50:00.565Z
8Nov 03, 2026, 03:55Tuein 38m 16sexact2026-11-03T03:55:00.565Z
9Nov 03, 2026, 04:00Tuein 43m 16sexact2026-11-03T04:00:00.565Z
10Nov 03, 2026, 04:05Tuein 48m 16sexact2026-11-03T04:05:00.565Z
Métrica principalAST válido y normalizado
Eficiencia y capacidad5 Campos (POSIX estándar)
Rendimiento neto10 SLOTS
Frecuencia anual estimadain 3m 16s
Resolución del motor24 / 24 HRS
Tasa de colisión100% Local (En memoria)
Referencia técnica y guía de arquitectura

Analizador Cron & Validador Crontab — Guía de referencia

Analiza expresiones cron y conviértelas en programaciones legibles. Inspecciona marcas de tiempo de próximas ejecuciones en distintas zonas horarias, valida la sintaxis de crontab y proyecta fechas futuras.

Analizador Cron & Validador Crontab — Guía de referencia — Arquitectura en memoria del lado del cliente y flujo de datos
Analizador Cron & Validador Crontab — Guía de referencia — Arquitectura en memoria del lado del cliente y flujo de datos

Parámetros clave y controles

Campo de minutos (Campo 1 en POSIX, Campo 2 en Quartz)Conjunto de enteros [0-59], asterisco (*), paso (/n), rango (a-b), lista (,)

Especifica el minuto exacto de la hora en que se dispara la tarea (0-59). Se evalúa mediante máscaras de bits de 60 bits con comprobaciones de pertenencia en O(1); la sintaxis de paso */15 se activa en los minutos 0, 15, 30 y 45 de cada hora.

Por defecto: 0 (Inicio de la hora / :00)
Campo de horas (Campo 2 en POSIX, Campo 3 en Quartz)Conjunto de enteros [0-23] en formato de 24 horas

Especifica la hora del día en formato militar de 24 horas (0-23), donde 0 representa la medianoche (00:00) y 23 representa las 23:00 (11:00 PM). El rango 9-17 coincide con las horas de oficina estándar según ISO 8601 en zonas horarias IANA.

Por defecto: * (Cada hora)
Campo de día del mes (Campo 3 en POSIX, Campo 4 en Quartz)Conjunto de enteros [1-31], signo de interrogación (?), último (L), día laborable más cercano (W)

Especifica el día calendario dentro del mes, de 1 a 31. Las fechas inválidas que exceden la duración del mes (por ejemplo, 31 en abril o 30 en febrero) se omiten de forma segura durante la verificación del calendario.

Por defecto: * (Todos los días)
Campo de mes (Campo 4 en POSIX, Campo 5 en Quartz)Conjunto de enteros [1-12] o alias de 3 letras [JAN-DEC]

Especifica el mes calendario del 1 (enero) al 12 (diciembre). Los sistemas POSIX admiten cadenas de 3 letras que no distinguen entre mayúsculas y minúsculas (JAN-DEC), mapeadas internamente a una máscara de bits de 12 bits.

Por defecto: * (Cada mes)
Campo de día de la semana (Campo 5 en POSIX, Campo 6 en Quartz)Conjunto de enteros [0-7] o alias de 3 letras [SUN-SAT], n-ésimo día (#), último (L)

Especifica el día de la semana. Bajo las especificaciones POSIX IEEE 1003.1 y Vixie cron, tanto el 0 como el 7 designan el domingo (1=lunes, ..., 6=sábado). Las abreviaturas insensibles a mayúsculas (SUN-SAT) eliminan la confusión de desfase por uno (off-by-one) entre dialectos.

Por defecto: * (Todos los días de la semana)
Campo de segundos (Campo 1 en Quartz / Spring, omitido en POSIX)Conjunto de enteros [0-59] de segundos de alta resolución

Primer campo extendido de alta resolución en planificadores de 6 campos (Quartz, Spring Framework). El crontab estándar de UNIX de 5 campos no admite segundos y procesa los tokens iniciales de 6 posiciones como sintaxis no válida.

Por defecto: 0 (Cero segundos)
Campo de año (Campo 7 opcional en Quartz, Campo 6 en AWS EventBridge)Conjunto de enteros [1970-2099], asterisco (*), omitido en POSIX

Campo final de año calendario opcional u obligatorio admitido por motores de planificación empresariales para acotar tareas recurrentes a años específicos sin provocar bucles de ejecución infinitos.

Por defecto: * (Sin límite / Cada año)

Consejos profesionales y mejores prácticas

La coexistencia de día del mes y día de la semana en POSIX opera como OR lógico, no AND

En las especificaciones estándar de Vixie y POSIX IEEE 1003.1, cuando tanto el día del mes (campo 3) como el día de la semana (campo 5) contienen valores distintos del comodín, el planificador los evalúa con una condición lógica OR. Por ejemplo, 0 0 13 * 5 NO se ejecuta exclusivamente los viernes 13; en realidad, se ejecuta el día 13 de cada mes Y además todos los viernes de cada mes. Para restringir la ejecución estrictamente al viernes 13, mantén el día de la semana como * y comprueba el día dentro del comando de bash: 0 0 13 * * [ $(date +\%u) -eq 5 ] && /opt/backup.sh.

Los valores de paso (*/N) se reinician en los límites del campo y generan saltos modulares no uniformes

Un error conceptual frecuente es asumir que */25 * * * * se ejecutará ininterrumpidamente cada 25 minutos. En realidad, las expresiones de paso cron se evalúan estrictamente dentro del rango de 0 a 59 minutos: 59 / 25 genera ejecuciones solo en el minuto 0, 25 y 50. Al avanzar a la siguiente hora (por ejemplo, de 01:50 a 02:00), el campo se reinicia al minuto 0, provocando un intervalo de 10 minutos en lugar de 25 minutos. Si requieres intervalos fijos reales entre horas, utiliza temporizadores monotónicos de Systemd (OnUnitActiveSec=25m) o colas de tareas.

Estandariza siempre el crontab del servidor en UTC para inmunizarlo contra cambios de hora (DST)

Ejecutar demonios de crontab en zonas horarias locales con horario de verano (DST) provoca anomalías graves. Durante el adelanto de primavera (+1 hora), las tareas programadas entre las 02:00 y las 02:59 se omiten por completo porque esa hora de reloj no existe. Durante el retraso de otoño (-1 hora), las tareas en esa franja se ejecutan dos veces. Configura siempre los relojes del sistema y el entorno de crontab con TZ=UTC, y calcula los desfases comerciales de forma estática para eliminar ejecuciones duplicadas u omitidas.

Los signos de porcentaje (%) en Vixie Cron deben escaparse con barras invertidas

En los archivos crontab, el signo de porcentaje % sin escapar posee un significado sintáctico especial: el demonio cron lo interpreta como un carácter de salto de línea y canaliza todos los datos posteriores a la entrada estándar (stdin) del comando. Intentar ejecutar comandos con formato como date +%Y-%m-%d provocará errores de sintaxis o la truncación silenciosa del script. Debes escapar cada porcentaje como date +\%Y-\%m-\%d o encapsular la llamada dentro de un script de shell ejecutable.

Problemas comunes y soluciones

⚠️Crontab arroja error de sintaxis al pegar una expresión de 6 o 7 campos en /etc/crontab de Linux

El crontab estándar de UNIX/Linux espera exactamente 5 campos delimitados por espacios. Las expresiones copiadas de Java Quartz, Spring Framework o AWS EventBridge incluyen un campo inicial de segundos (por ejemplo, 0 0 12 * * ?) o un campo final de año. Al pegarlas en un crontab estándar, el sexto token se interpreta como el usuario o el comando, provocando un fallo sintáctico. Elimina el token de segundos inicial y el año final, y convierte los comodines ? en asteriscos estándar *.

⚠️La tarea de cron se ejecuta a una hora local incorrecta o inesperada

El demonio crontab evalúa las programaciones respecto a la zona horaria del hardware y del kernel (/etc/timezone o /etc/localtime). En entornos en la nube (AWS EC2, contenedores Docker, nodos de Kubernetes), el reloj del sistema opera en UTC por defecto. Una tarea configurada como 0 9 * * 1-5 pensada para las 9:00 AM hora local se disparará a las 9:00 AM UTC. Declara explícitamente CRON_TZ=Europe/Madrid (o tu zona horaria IANA) en la cabecera del archivo crontab (Vixie cron 4.1+) o convierte directamente tu horario a UTC.

⚠️La tarea de cron no se ejecuta o no encuentra variables de entorno ($PATH)

Cron ejecuta las tareas en una shell limpia, no interactiva y sin inicio de sesión (non-login), con un PATH mínimo predeterminado (habitualmente /usr/bin:/bin). Las herramientas instaladas en /usr/local/bin, ~/.nvm o /opt/homebrew fallarán con errores command not found. Define un PATH=/usr/local/bin:/usr/bin:/bin explícito en la parte superior del crontab o invoca todos los ejecutables mediante rutas absolutas (por ejemplo, /usr/bin/python3 /opt/app/job.py).

⚠️Frecuencia de doble ejecución inesperada al combinar día del mes y día de la semana

Tal como estipula el estándar POSIX IEEE 1003.1, cuando tanto el día del mes como el de la semana se definen con valores distintos de *, la evaluación opera como una condición OR y no como una conjunción AND. La tarea se disparará siempre que coincida el día del mes O cuando coincida el día de la semana. Para exigir una coincidencia simultánea, fija el día de la semana en * e incorpora una comprobación POSIX de fecha en el comando: 0 3 1-7 * * [ $(date +\%u) -eq 1 ] && /opt/primer-lunes.sh.

Preguntas frecuentes (FAQ)

¿Cómo se calcula la fecha y hora exacta de la próxima ejecución de una expresión cron?▼

La próxima ejecución se calcula haciendo avanzar una marca de tiempo base ISO 8601 minuto a minuto (o segundo a segundo en motores de 6 campos) y evaluando cada candidato frente a máscaras de bits de 64 bits precompiladas mediante operaciones bitwise AND con complejidad de paso O(n). Cuando todos los campos coinciden simultáneamente —sujeto a la lógica de unión OR entre DOM y DOW de POSIX—, la marca temporal se registra como un instante válido. En el navegador, todo el análisis AST y la proyección se ejecutan en la memoria aislada de JavaScript sin consultar servidores externos.

¿Cuál es la diferencia entre el cron estándar de 5 campos de Linux y el de 6 campos de Quartz?▼

El cron estándar POSIX/Linux utiliza 5 campos delimitados por espacios (minuto, hora, día del mes, mes y día de la semana) con granularidad de 1 minuto, mientras que los programadores de Java Quartz y Spring Framework emplean 6 o 7 campos al anteponer un campo obligatorio de segundos (0-59) y admitir opcionalmente un campo de año (1970-2099). Además, Quartz introduce caracteres especiales como ? (campo sin restricción) y L (último día del mes o semana), que generan errores de sintaxis irrecuperables en crontabs estándar de UNIX.

¿Cuál es la diferencia entre el asterisco (*) y la barra diagonal (/paso) en la sintaxis cron?▼

El asterisco (*) actúa como un comodín sin restricciones que coincide con todos los enteros válidos dentro del dominio de ese campo (por ejemplo, los minutos del 0 al 59), mientras que la barra (/paso) define un intervalo modular que evalúa solo saltos discretos a partir de un índice base dentro de los límites del campo. Por ejemplo, */15 coincide con los minutos 0, 15, 30 y 45, mientras que 10-30/5 limita la secuencia estrictamente al rango delimitado para evaluar 10, 15, 20, 25 y 30.

¿Por qué 0 0 13 * 5 se ejecuta todos los viernes en lugar de únicamente los viernes 13?▼

Según el estándar POSIX IEEE 1003.1, si tanto el día del mes (campo 3) como el de la semana (campo 5) contienen valores distintos de comodín (*), el programador los evalúa con una disyunción lógica OR en lugar de una conjunción lógica AND. En consecuencia, la tarea se ejecuta el día 13 de cualquier mes y también todos los viernes, independientemente de la fecha. Para forzar una condición AND, establece el día de la semana en * y valida el día dentro del comando con [ $(date +\%u) -eq 5 ].

¿Qué significan los caracteres de signo de interrogación (?) y L en expresiones cron?▼

En los dialectos de Quartz, Spring y AWS EventBridge, el signo de interrogación (?) indica la ausencia de un valor específico para evitar conflictos de ambigüedad entre el día del mes y el de la semana, mientras que la letra L representa Last (último, como el último día del mes o el último viernes con 5L). Los crontabs estándar POSIX IEEE 1003.1 no reconocen ? ni L y rechazan las expresiones que los incluyan considerándolas sintaxis inválida.

¿Cómo afectan los cambios de hora por horario de verano (DST) a las tareas de cron?▼

Durante el adelanto de 1 hora en primavera (DST), las tareas programadas dentro de la franja horaria que se salta (típicamente de 02:00:00 a 02:59:59) se omiten por completo porque esa hora de reloj nunca transcurre. Por el contrario, durante el retraso de 1 hora en otoño, las tareas ubicadas en esa ventana repetida se ejecutan dos veces a menos que se use UTC. Para evitar ejecuciones omitidas o duplicadas, los servidores de producción deben operar siempre con sus relojes de hardware y procesos de crontab en UTC.

Herramientas y utilidades relacionadas

Todas las herramientas →