Saltar al contenido
Aback Tools Logo

Resolvedor de Cron: Entender las Expresiones Cron

Cómo leer, escribir y validar expresiones cron: sintaxis campo por campo, caracteres especiales, patrones de programación comunes, diferencias entre plataformas, errores frecuentes y herramientas gratuitas para resolver y simular programaciones.

DH
Tutorials & How-Tos12 min de lectura2,700 palabras

Las expresiones cron parecen crípticas a primera vista: cinco campos separados por espacios llenos de asteriscos, números, barras y comas. Pero hay una lógica consistente en cada campo y, una vez que la entiendes, leer y escribir programaciones cron se vuelve sencillo. Esta guía desglosa cada parte de la sintaxis cron, explica los caracteres especiales, muestra los patrones de programación más comunes y cubre las herramientas que resuelven, validan y simulan expresiones cron antes de desplegarlas.

5Campos cron estándarminuto, hora, día del mes, mes, día de la semana
15+Preajustes de programación integradosen el Crontab Expression Builder
12moHorizonte de simulaciónen el Interactive Cron Scheduler

¿Qué es una expresión cron?

Una expresión cron es una cadena de cinco (o a veces seis) campos separados por espacios que define una programación recurrente para tareas automatizadas. El formato se inventó con el demonio cron de Unix a principios de los años 70 y se ha mantenido esencialmente sin cambios desde entonces. Hoy se usa en archivos crontab de Linux, en pipelines de CI/CD como GitHub Actions y GitLab CI, en programadores en la nube como AWS EventBridge y Google Cloud Scheduler, en orquestadores de contenedores como Kubernetes CronJob y en frameworks de aplicaciones como Spring y Quartz.

La anatomía de una expresión cron

El formato estándar de cinco campos es:

formato de expresión cron
text
┌----------- minuto        (0-59)
│ ┌--------- hora          (0-23)
│ │ ┌------- día del mes  (1-31)
│ │ │ ┌----- mes         (1-12)
│ │ │ │ ┌--- día de la semana   (0-7, domingo = 0 o 7)
│ │ │ │ │
* * * * *   comando a ejecutar

Los campos se leen de izquierda a derecha: minuto, hora, día del mes, mes, día de la semana. La expresión "0 9 * * 1-5" se ejecuta a las 09:00 cada día laborable. Cada campo puede contener un valor único, una lista separada por comas, un rango, un paso, un comodín o una combinación. Entender estos operadores es toda la habilidad de leer cron.

Note

Algunas plataformas usan un formato de 6 campos que añade un campo de segundos en la posición 0 (antes de los minutos). Spring Scheduler y Quartz usan este formato. AWS EventBridge y la mayoría de demonios cron de Unix usan 5 campos. Comprueba siempre qué formato espera tu plataforma de destino: una expresión escrita para una puede producir silenciosamente una programación incorrecta en otra.

Sintaxis de la expresión cron campo por campo

Cada campo tiene un rango definido de valores enteros válidos. Los valores fuera del rango válido producen un error o una mala configuración silenciosa según la implementación de cron. Entender el rango válido de cada campo es la base para leer cualquier expresión cron.

Rangos válidos de cada campo

  • Minuto - de 0 a 59. El valor 0 es el inicio de la hora; el valor 59 es un minuto antes de la siguiente hora.
  • Hora - de 0 a 23. Usa formato de 24 horas: 0 es medianoche, 12 es mediodía, 23 son las 11 PM.
  • Día del mes - de 1 a 31. Los días se indexan desde 1. Algunos meses tienen menos días: febrero tiene 28 o 29, y abril/junio/septiembre/noviembre tienen 30.
  • Mes - de 1 a 12. Enero es 1, diciembre es 12. Algunas implementaciones también aceptan abreviaturas de tres letras: JAN, FEB, MAR, etc.
  • Día de la semana - de 0 a 7. Tanto 0 como 7 representan el domingo. El lunes es 1, el sábado es 6. Algunas implementaciones admiten MON, TUE, WED, THU, FRI, SAT, SUN.

Cómo interactúan los campos

Los cinco campos se evalúan juntos como un AND lógico: el trabajo se ejecuta cuando todos los campos sin comodín coinciden simultáneamente. "0 9 15 * *" se ejecuta exactamente a las 09:00 el día 15 de cada mes. La excepción crítica es cuando tanto el día del mes como el día de la semana tienen valores sin comodín: en ese caso, la mayoría de demonios cron se ejecutan si CUALQUIERA de las condiciones es verdadera (un OR lógico), no ambas. Esta es una fuente notoria de comportamientos inesperados.

Warning

El comportamiento OR entre día del mes y día de la semana es uno de los errores más comunes de cron. "0 9 1 * 1" NO significa "el primer lunes del mes a las 09:00": significa "09:00 el día 1 del mes, O 09:00 cualquier lunes". Usa un script o un programador gestionado con lógica de calendario si necesitas la semántica real de "primer lunes del mes".

Caracteres especiales explicados

El poder de cron proviene de sus caracteres especiales: los operadores que convierten valores fijos en patrones de programación flexibles. Dominar estos seis operadores cubre prácticamente todos los patrones de programación que encontrarás.

Los seis operadores básicos

CarácterNombreEjemploSignificado
*Comodín* en minutoTodos los valores válidos (0-59 para minutos)
,Lista1,15,30 en minutoEn los minutos 1, 15 y 30
-Rango1-5 en día de la semanaDe lunes a viernes (días 1 a 5)
/Paso*/15 en minutoCada 15 minutos (0, 15, 30, 45)
?Sin especificar? en día del mesSin valor específico (solo Quartz/Spring)
@Macro@dailyAlias abreviados (@daily = 0 0 * * *)

Combinar operadores

Los operadores se pueden combinar dentro de un mismo campo. "0,30 9-17 * * 1-5" significa "en los minutos 0 y 30 de cada hora de 9 AM a 5 PM, de lunes a viernes". La sintaxis de paso también puede aplicarse a un rango: "0-30/5" en el campo de minuto significa cada 5 minutos desde el minuto 0 hasta el 30 (0, 5, 10, 15, 20, 25, 30). El Traductor de Cron a Lenguaje Humano desglosa cualquier combinación en lenguaje claro con explicaciones campo por campo.

Tip

Al leer una expresión cron desconocida, analiza cada campo de izquierda a derecha y tradúcelo de forma independiente. Primero el campo de minuto, luego la hora, luego el día del mes, luego el mes y por último el día de la semana. Lee cada campo sin asterisco como una restricción: "solo cuando minuto = X", "solo cuando hora = Y", etc. El resultado se lee como una frase al ensamblarlo en orden inverso, de derecha a izquierda.

Patrones de programación cron comunes

La mayoría de las programaciones cron del mundo real caen en un puñado de patrones recurrentes. Conocer estos patrones de vista te permite leer la mayoría de crontabs de producción sin referencia.

  1. "* * * * *" - Cada minuto. La programación más frecuente posible. Se usa para comprobaciones de latido y monitoreo.
  2. "*/5 * * * *" - Cada 5 minutos. Común para trabajos de sondeo y calentamiento de caché.
  3. "0 * * * *" - Cada hora en punto. Estándar para procesos por lotes horarios.
  4. "0 0 * * *" - Diariamente a medianoche (UTC). El valor por defecto para trabajos de limpieza diaria.
  5. "0 9 * * 1-5" - 9 AM cada día laborable. Programación estándar en horario laboral.
  6. "0 0 1 * *" - Medianoche el día 1 de cada mes. Ejecuciones de facturación mensual, generación de informes.
  7. "0 0 1 1 *" - Medianoche el 1 de enero. Trabajos anuales: renovaciones de licencias, informes de fin de año.
  8. "0 0 * * 0" - Medianoche cada domingo. Ventanas de mantenimiento semanales.

Construir programaciones personalizadas a partir de patrones

La mayoría de las programaciones complejas son combinaciones de estos patrones. "0 2 * * 6,0" significa "2 AM los sábados y domingos": la ventana de mantenimiento del fin de semana. "*/10 8-18 * * 1-5" significa "cada 10 minutos de 8 AM a 6 PM, solo días laborables". Si conoces la programación objetivo en lenguaje claro, el Crontab Expression Builder te permite configurar cada campo visualmente y genera la expresión correcta con una confirmación legible y las próximas cinco ejecuciones.

Crontab Expression Builder

Crea expresiones cron visualmente con 15 preajustes, 5 modos de campo, descripción instantánea en lenguaje claro y vista previa de las próximas 5 ejecuciones: gratis, sin registro.

Open tool

Cómo crear y validar expresiones cron

Escribir una expresión cron desde cero y esperar que sea correcta es arriesgado. Un solo campo transpuesto o un operador mal entendido puede hacer que un trabajo se ejecute a horas completamente equivocadas, o que nunca se ejecute. Estas herramientas eliminan ese riesgo.

1

Escribe o selecciona tu expresión

Abre el Crontab Expression Builder y escribe tu expresión directamente o elige entre los 15 preajustes integrados. Cada preajuste cubre un patrón de programación común (cada minuto, horario, diario, días laborables, mensual) y puede ajustarse con los controles visuales de campo sin tocar la expresión en bruto.

2

Valida los errores de sintaxis

Pega la expresión en el Validador de Expresiones Cron. Comprueba cada campo contra su rango válido, valida los límites de los rangos (el inicio debe ser menor que el fin), confirma que los valores de paso no son cero y marca las macros no compatibles con el crontab estándar de 5 campos. Cada error incluye un mensaje a nivel de línea que explica qué esperaba el analizador.

3

Traduce a lenguaje claro

Pasa la expresión validada por el Traductor de Cron a Lenguaje Humano. La salida es una frase completa en lenguaje claro que describe la programación - "A las 2:30 AM, los lunes, miércoles y viernes" - más un desglose campo por campo. Si la descripción no coincide con tu intención, revisa la expresión antes de desplegar.

4

Simula las próximas 12 meses de ejecuciones

Para trabajos programados donde el momento importa - ejecuciones de facturación, exportaciones de datos, ventanas de mantenimiento - abre el Interactive Cron Scheduler y simula la expresión durante los próximos 12 meses. La vista de calendario muestra la densidad mensual de ejecuciones y la línea de tiempo muestra las marcas de tiempo exactas. Confirma que la programación se ejecuta en las fechas esperadas antes de fusionar la configuración a producción.

Validador de Expresiones Cron

Valida sintaxis cron de 5 campos, rangos, pasos, valores de lista y macros con diagnósticos instantáneos por campo: local en el navegador, gratis, sin registro.

Open tool

Cron en CI/CD y programadores en la nube

La sintaxis cron se usa mucho más allá del crontab de Linux. Las plataformas modernas de CI/CD y nube han adoptado el mismo formato de 5 campos, pero cada una tiene sus peculiaridades en el manejo de zonas horarias, soporte de macros y restricciones de intervalo mínimo.

Diferencias plataforma por plataforma

PlataformaCamposZona horariaMacrosIntervalo mínimo
Linux crontab5Local del sistema✓ Las 6Cada minuto
GitHub Actions5Solo UTC✗ NingunaCada 5 min (deriva forzada de 15 min)
GitLab CI5Solo UTC✓ ParcialCada minuto
AWS EventBridge5 o 6Solo UTC✗ NingunaCada minuto
Google Cloud Scheduler5 o unixCualquier zona IANA✓ AlgunasCada minuto
Kubernetes CronJob5Zona del clúster✗ NingunaCada minuto
Spring Scheduler6Por defecto de la JVM✓ SíCada segundo

Programación cron en GitHub Actions

GitHub Actions usa la sintaxis cron estándar de 5 campos pero siempre se ejecuta en UTC. Si quieres un trabajo a las 9 AM hora del Este (UTC-5), escribes "0 14 * * *". GitHub Actions tampoco admite sintaxis de macros (@daily, @weekly), así que usa la expresión completa. Los flujos programados durante periodos de alta carga pueden ejecutarse hasta 15 minutos tarde: diseña tus trabajos para tolerar esta deriva.


Convertir cron a temporizadores systemd

Los sistemas Linux modernos usan cada vez más temporizadores systemd en lugar del crontab clásico. El formato OnCalendar de systemd usa una sintaxis diferente pero cubre los mismos patrones. El Convertidor de Cron a Temporizador Systemd convierte cualquier expresión cron de 5 campos a su configuración equivalente de unidad de temporizador systemd, incluyendo una plantilla completa de archivos .timer y .service.

Errores y casos límite de cron

Incluso los desarrolladores experimentados encuentran fallos silenciosos con cron. Estos son los errores más comunes: cada uno ha costado a sistemas de producción tiempo de inactividad inadvertido o ejecuciones duplicadas de trabajos.

Sorpresas de zona horaria

Cron se ejecuta por defecto en la zona horaria local del servidor. Si tu servidor está en UTC pero tu negocio está en Nueva York (UTC-5), "0 9 * * *" se ejecuta a las 4 AM hora local, no a las 9 AM. Las plataformas en la nube como GitHub Actions y AWS EventBridge siempre se ejecutan en UTC, lo que significa que todo el cálculo de zonas horarias recae en ti. Confirma siempre la zona horaria antes de desplegar una programación. El Interactive Cron Scheduler te permite simular ejecuciones con el desfase horario aplicado.

Casos límite de fin de mes

Programar un trabajo el día 29, 30 o 31 del mes hace que omita silenciosamente los meses que no tienen esa fecha. "0 0 31 * *" nunca se ejecuta en abril, junio, septiembre o noviembre. "0 0 29 2 *" se ejecuta en febrero solo en años bisiestos. Si necesitas una programación de "último día del mes", necesitas un enfoque más inteligente: o ejecutar a diario con un script que compruebe la fecha, o usar un programador en la nube que admita la sintaxis L (último) día.

Transiciones de horario de verano

Las transiciones del horario de verano pueden hacer que los trabajos cron se ejecuten dos veces o se omitan. Cuando los relojes adelantan, las horas dentro de la hora saltada nunca ocurren. Cuando los relojes atrasan, las horas dentro de la hora repetida ocurren dos veces. Los trabajos programados en una zona horaria local durante la ventana de transición se ven afectados. La práctica más segura es ejecutar servidores y programadores en UTC, que nunca tiene transiciones de horario de verano.

Warning

Nunca confíes en cron para ejecuciones exactas y críticas en el tiempo. Los demonios cron pueden perder una ejecución si el sistema está caído, reiniciando, bajo carga pesada o si el reloj se ajusta. Para transacciones financieras, un diseño de trabajo idempotente y una cola de trabajos con manejo de mensajes muertos son más fiables que la programación cron en bruto.

El problema de cada segundo

El cron estándar de 5 campos tiene una resolución mínima de un minuto. Si necesitas que un trabajo se ejecute cada 10 segundos, cron no es la herramienta adecuada: usa un temporizador del sistema, una cola de trabajos con retardos o el campo de segundos disponible en Spring Scheduler y Quartz. Intentar aproximar programaciones de menos de un minuto con múltiples entradas de crontab es propenso a errores y crea condiciones de carrera cuando los trabajos se solapan.

Key takeaways

  • Una expresión cron tiene cinco campos: minuto (0-59), hora (0-23), día del mes (1-31), mes (1-12), día de la semana (0-7).
  • Los seis caracteres especiales son * (comodín), , (lista), - (rango), / (paso), ? (sin especificar, solo Quartz) y @ (macros como @daily).
  • Cuando tanto el día del mes como el día de la semana son valores sin comodín, la mayoría de demonios cron se ejecutan si CUALQUIERA coincide - una fuente común de dobles ejecuciones inesperadas.
  • Usa el Crontab Expression Builder para construir visualmente, el Validador de Expresiones Cron para comprobar la sintaxis y el Interactive Cron Scheduler para simular 12 meses de ejecuciones.
  • GitHub Actions usa cron de 5 campos solo UTC sin soporte de macros; AWS EventBridge y Google Cloud Scheduler también usan UTC; el crontab de Linux usa la zona horaria local del sistema.
  • No programes el día 29, 30 o 31 si necesitas que el trabajo se ejecute cada mes - esos días no existen en todos los meses.
  • El cron estándar tiene una resolución mínima de un minuto; usa temporizadores systemd, colas de trabajos o Spring/Quartz para necesidades de programación de menos de un minuto.

Preguntas frecuentes

A cron resolver is a tool that parses a cron expression and translates it into a human-readable schedule description and a list of the next scheduled run times. Given an expression like "0 9 * * 1-5", a resolver tells you "At 09:00 AM, Monday through Friday" and shows you the next five dates and times the job will fire. The Aback Tools Cron to Human-Readable Translator and Interactive Cron Scheduler both perform this resolution instantly in your browser without uploading anything to a server.

The five fields are minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-7, where both 0 and 7 represent Sunday). They run left to right in that order. The expression "30 8 * * 1" means "At 8:30 AM, every Monday." An asterisk (*) in any field means "every valid value for that field." Most standard crontab implementations use exactly these five fields; some extended formats (Spring Scheduler, Quartz) add a sixth seconds field at the start.

An asterisk (*) is the wildcard character in cron - it means "match every valid value for this field." In the minute field, * means every minute (0-59). In the hour field, * means every hour (0-23). In the day-of-week field, * means every day. So "* * * * *" runs every minute of every hour every day. It is the broadest possible value for any field. Use it when a field should not restrict the schedule rather than listing every value explicitly.

Range syntax specifies a span of consecutive values: "1-5" in the day-of-week field means Monday through Friday. Step syntax uses a forward slash to specify an interval: "*/15" in the minute field means every 15 minutes (0, 15, 30, 45). They can be combined: "0-30/10" means every 10 minutes from minute 0 to minute 30 (0, 10, 20, 30). Step syntax is commonly used to run jobs at regular intervals without listing every value explicitly.

Use the step syntax in the minute field: "*/5 * * * *". This expression fires at minutes 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, and 55 of every hour, every day. If you need to run every 5 minutes but only during business hours (9 AM to 5 PM, Monday to Friday), use "*/5 9-17 * * 1-5". Validate the expression in the Cron Expression Validator and preview the exact fire times in the Interactive Cron Scheduler before deploying.

Cron macros are shorthand aliases for common schedule expressions. The most widely supported are @reboot (run once at startup), @yearly or @annually ("0 0 1 1 *"), @monthly ("0 0 1 * *"), @weekly ("0 0 * * 0"), @daily or @midnight ("0 0 * * *"), and @hourly ("0 * * * *"). Support varies by scheduler - Linux crontab and most Unix cron daemons support all six; AWS EventBridge, Google Cloud Scheduler, and GitHub Actions do not support macro syntax. The Cron to Human-Readable Translator handles macros and expands them to their equivalent expressions.

The most common causes are timezone mismatch (cron runs in the server's local timezone, often UTC), off-by-one in day-of-week numbering (0 and 7 both mean Sunday on most systems, but not all), and the interaction between day-of-month and day-of-week fields (when both are non-wildcard, most cron implementations fire if EITHER condition is true, not both). Use the Interactive Cron Scheduler to simulate the exact fire times in UTC versus your expected timezone before concluding there is a bug.

Yes. GitHub Actions supports cron scheduling via the `schedule` trigger with a `cron:` key using standard 5-field cron syntax. GitHub Actions runs on UTC, so adjust your expression accordingly. Note that GitHub Actions does not support cron macros (@daily, @weekly, etc.) - use the full 5-field expression instead. Also, scheduled workflows may not run at exactly the specified time during periods of high load; expect up to 15 minutes of drift. The Crontab Expression Builder generates GitHub Actions-compatible expressions with next run time previews.

ShareXLinkedIn