Expresión cron: leer la sintaxis y calcular las próximas ejecuciones
Lee una expresión cron campo a campo, comprueba sus próximas ejecuciones en UTC o en hora local y evita las trampas de pasos, zonas horarias y dialectos.
Una expresión cron se lee campo a campo y se comprueba con fechas
Una línea como */15 9-17 * * 1-5 gobierna una copia de seguridad, un workflow de CI o un CronJob de Kubernetes. Es corta y casi nadie la relee. Si lees mal un campo, la tarea se lanza a una hora equivocada, dos veces o nunca. El analizador cron acepta cinco campos (minuto, hora, día del mes, mes, día de la semana) o seis, con los segundos al principio. También acepta alias como @daily y @hourly. Muestra una frase que resume la programación y el valor de cada campo. Además, da las próximas 5, 10 o 25 ejecuciones, en UTC o en la zona horaria de tu navegador. El cálculo se hace en tu pestaña y la expresión no se envía a nadie. Esta guía repasa la sintaxis y los alias, y después enseña a leer el resultado. Después vienen las trampas que salen caras. Un paso no cuadra, dos campos de día se combinan en un OR, una fecha no existe, y la zona horaria y el cambio de hora del 25 de octubre de 2026 lo desplazan todo. Al final compara los dialectos de crontab, Kubernetes, GitHub Actions y AWS EventBridge, y rehace los cálculos en código. Las herramientas relacionadas están en el hub de utilidades para desarrolladores.
Para qué sirve el analizador y dónde termina
El analizador responde a una sola pregunta: ¿en qué momentos se dispara esta expresión? Úsalo para comprobarlo antes de desplegar.
El analizador calcula fechas. El resto de la cadena se comprueba en otra parte.
Leer los resultados sin equivocarse
Introduce la expresión en el analizador cron. Las fechas de abajo parten del viernes 16 de octubre de 2026 a las 12:00 UTC. La herramienta parte del momento actual, así que tus fechas serán otras.
Un paso se calcula dentro del rango del campo. Al comienzo de cada rango, la cuenta vuelve a cero.
Cuando los dos campos están rellenos, cron no los combina con AND. Lanza la tarea si coincide cualquiera de los dos (según la página de manual de crontab). La herramienta lo señala con una nota bajo la frase de resumen.
Una expresión válida puede no dispararse nunca. La herramienta busca unos dos años hacia delante y te lo dice.
Cuatro errores que solo se ven en producción
El analizador calcula siempre en UTC. La opción Local solo cambia cómo se escriben las fechas encontradas. 0 9 * * * da las 09:00 UTC, que la herramienta escribe como 11:00 en un navegador configurado en París el 16 de octubre de 2026. Un cron lanzado en un servidor configurado en París se dispara a las 09:00 hora de París, es decir, a las 07:00 UTC hasta el 24 de octubre y a las 08:00 UTC después. La zona que se aplica depende del sistema que ejecuta la tarea. El demonio cron sigue la zona horaria de la máquina. Un CronJob de Kubernetes sigue la del kube-controller-manager, salvo que se indique .spec.timeZone. GitHub Actions cuenta en UTC por defecto.
Europa pasa al horario de invierno el domingo 25 de octubre de 2026. A las 03:00 hora de verano vuelven a ser las 02:00. Estados Unidos cambia una semana después, el 1 de noviembre. Una tarea fijada en 30 2 * * * se topa entonces con una hora que existe dos veces al retrasar el reloj, o que no existe al adelantarlo. Las implementaciones no coinciden. La página de manual de Debian de cron(8) indica que las tareas de la hora saltada se lanzan poco después del cambio y que las de la hora repetida no se vuelven a ejecutar. La página crontab(5) publicada en man7.org dice lo contrario. Una hora que no existe nunca coincide, y una hora repetida se dispara dos veces. GitHub Actions, con la clave timezone, adelanta una ejecución que cae en la hora saltada hasta la siguiente hora válida.
La misma programación se escribe distinto según la herramienta. AWS EventBridge añade un campo de año y exige un ? en uno de los dos campos de día. Quartz y Spring ponen los segundos primero. El analizador rechaza lo que no conoce y nombra el campo y el token en cuestión, por ejemplo «Valor no válido en Día del mes (?)».
Una expresión correcta no garantiza que la tarea arranque, ni que arranque una sola vez. La documentación de Kubernetes avisa de que la creación de un Job es aproximada: pueden crearse dos Jobs o ninguno, y por eso las tareas deben ser idempotentes. La política de concurrencia por defecto es Allow, que deja arrancar una ejecución mientras la anterior sigue en marcha. Si el controlador cuenta más de 100 arranques perdidos, deja de lanzar la tarea y registra un error. GitHub Actions retrasa las ejecuciones programadas cuando hay mucha carga, sobre todo al comienzo de cada hora, y puede descartar alguna. En un repositorio público, los workflows programados se desactivan tras 60 días sin actividad.
Campos, alias y dialectos de un vistazo
Todos los campos aceptan los mismos operadores. Solo cambian los límites.
Un alias sustituye a toda la expresión. El analizador los desarrolla en el cuadro de entrada.
Antes de copiar una expresión, comprueba qué entiende el destino.
El analizador cron, paso a paso
El analizador cron analiza mientras escribes, tras una breve pausa. El botón Analizar, o la tecla Intro dentro del campo, lanza el cálculo sin esperar.
Escribe o elige un ajuste predefinido
Seis ajustes rellenan el campo: cada 5 minutos, cada 15 minutos, cada hora, todos los días a medianoche, días laborables a las 09:00 y el día 1 de cada mes. Un alias como @daily se sustituye por su forma de cinco campos.
Lee la frase
Para las programaciones sencillas, una frase resume la expresión, por ejemplo «Cada 15 minutos» o «A las 09:00 en días laborables (lun–vie)». Si no, la herramienta muestra «Desglose de la programación» y te deja leer los campos.
Revisa las casillas
Cada casilla lleva el nombre de un campo y su valor. Aparece una nota cuando el día del mes y el día de la semana están ambos fijados, para recordar que basta con uno de los dos.
Lee las próximas ejecuciones
La lista da las fechas completas, con una línea «Próxima» que indica lo que falta para la primera. Aparece un aviso si no existe ninguna fecha o si la búsqueda termina antes de encontrar suficientes.
Tres ajustes bajo el campo de entrada cambian lo que la herramienta calcula o muestra.
Cinco o seis campos
Cinco campos es el ajuste inicial. Pasar a seis añade 0 al principio de la expresión, es decir, segundos a cero. Volver a cinco quita ese cero, y la herramienta lo rechaza mientras los segundos valgan algo distinto de 0.
Ejecuciones a mostrar
Elige 5, 10 o 25. Toma 25 para ver el patrón de un paso, de un fin de mes o de dos campos de día combinados.
Zona horaria
UTC es el ajuste inicial. Local usa la zona horaria de tu navegador. Una etiqueta sobre la frase recuerda la elección. El cálculo sigue en UTC en los dos casos: solo cambia cómo se escriben las fechas.
Copiar
Copiar descripción toma la frase, Copiar todo toma la lista, y cada línea tiene su propio botón Copiar.
Cuando la expresión se rechaza, la herramienta explica por qué y no calcula nada.
Expresión vacía
Un campo que se vacía después de escribir muestra «Introduce una expresión cron».
Número de campos incorrecto
«Expresión cron no válida para el número de campos seleccionado» indica cuatro campos, o seis con el ajuste en cinco. Cambia el ajuste o corrige los tokens.
Valor no válido
Un mensaje como «Valor no válido en Hora (22-2)» nombra el campo y el token en cuestión, y la casilla de ese campo se resalta.
Alias no admitido
@reboot y cualquier alias fuera de la lista dan un mensaje que recuerda los que la herramienta acepta.
Las mismas programaciones en un crontab, Kubernetes, GitHub Actions y Node
La línea se escribe en crontab -e. El comando ocupa el resto de la línea: un % sin proteger se convierte allí en un salto de línea, de ahí el \% del ejemplo (según la página de manual de crontab). Cron no ejecuta tu perfil de inicio de sesión, así que da la ruta completa de los programas.
Ejemplo básico
La zona horaria se declara en .spec.timeZone, nunca en schedule. Comprueba el manifiesto con el validador de Kubernetes antes de aplicarlo.
Ejemplo básico
El workflow solo se dispara si existe en la rama por defecto. El validador de GitHub Actions comprueba el archivo, y el analizador cron las fechas.
Ejemplo básico
Para calcular las próximas ejecuciones en una zona horaria, como hace un cron de verdad, pasa la opción tz. El ejemplo usa la versión 5 de la biblioteca. Muestra la diferencia con el analizador de FastMinify, que calcula en UTC: la misma línea da 07:00 UTC antes del 25 de octubre de 2026 y 08:00 UTC después, para una hora de París.
Ejemplo básico
Conclusión
Una expresión cron cabe en cinco campos, y casi todo el error viene de lo que no se ve en ella. Un paso vuelve a empezar de cero, dos campos de día se combinan en un OR, una fecha no existe, y una zona horaria o un cambio de hora lo desplaza todo. El analizador cron pone fechas junto a la línea, y así puedes detectar estos casos antes del despliegue. Calcula en UTC, no lanza ninguna tarea y solo conoce los cinco o seis campos y los alias habituales. El destino cuenta tanto como la expresión, porque crontab, Kubernetes, GitHub Actions, EventBridge y Quartz no leen la misma sintaxis. Escribe tareas que se puedan repetir sin daño y vigila su último éxito. El hub de utilidades para desarrolladores reúne las herramientas relacionadas.
Analizar una expresión cron en tu navegador
Artículos relacionados
Calcula red, máscara, rango de hosts y broadcast de un CIDR, resume rangos en bloques mínimos y comprueba una IP, todo en tu navegador, sin subir nada.
Formatea un Copy as cURL, analiza una petición o respuesta HTTP en bruto y lee un export HAR en tu navegador: no se envía ni se repite nada.
Decodifica la cabecera y el payload de un JWT o firma un token de prueba en tu navegador: HS256, RS256, ES256, sin enviar el secreto a un servidor ajeno.