Cron es el programador de trabajos más antiguo y ampliamente desplegado en computación — el cron original de Unix salió en 1975 y su sintaxis de expresión ha sido heredada esencialmente sin cambios por todos los sistemas de programación modernos, desde los crontabs de Unix hasta los CronJobs de Kubernetes y los programadores en la nube de AWS, GCP y Azure. A pesar de esa ubicuidad, las expresiones cron son célebremente propensas a errores cuando se escriben a mano, y un solo carácter equivocado puede convertir un trabajo diario en uno cada hora que tumbe un sistema en producción. Las secciones a continuación explican la estructura de 5 campos, los caracteres especiales que la extienden y los detalles prácticos que atrapan incluso a ingenieros con experiencia.
La Estructura de 5 Campos y Qué Significa Cada Uno
Una expresión cron estándar tiene exactamente 5 campos separados por espacios en un orden fijo: minuto, hora, día del mes, mes, día de la semana. Cada campo acepta un número dentro de su rango válido (minuto 0–59, hora 0–23, día del mes 1–31, mes 1–12, día de la semana 0–6 con 0 = domingo), un comodín `*` que significa cualquier valor o cualquiera de las sintaxis especiales que se describen en la siguiente sección. Los campos siguen un patrón de acercamiento cronológico: el minuto es el más preciso, el día de la semana es el más general para los patrones semanales. Un detalle complicado es el campo del día de la semana: históricamente diferentes variantes de Unix no estaban de acuerdo sobre si el domingo era 0 o 7, y el estándar moderno acepta ambos por compatibilidad. Los campos de mes y día de la semana también aceptan abreviaturas de tres letras (`JAN`-`DEC`, `SUN`-`SAT`), que no distinguen entre mayúsculas y minúsculas y, a menudo, son más legibles que los valores numéricos. Cuando se especifican tanto el día del mes como el día de la semana, la mayoría de las implementaciones cron usan la lógica OR (el trabajo se ejecuta cuando cualquiera de ellos coincide), no la lógica AND (se requiere que ambas coincidan). Esta es una de las fuentes de confusión más comunes: `0 0 15 * FRI` se ejecuta a la medianoche del día 15 de cada mes Y todos los viernes, no solo los viernes que caen el día 15.
Caracteres Especiales: Paso, Rango, Lista y Comodines
Cuatro caracteres especiales extienden la sintaxis básica de cron y cubren la mayoría de las necesidades reales de programación. El asterisco `*` es el comodín de cada-valor: `* * * * *` se dispara cada minuto de cada hora de cada día. La barra `/` introduce valores de paso: `*/15` en el campo de minuto se dispara en el minuto 0, 15, 30, 45 — cada 15 minutos. Los pasos pueden combinarse con rangos: `9-17/2` se dispara en las horas 9, 11, 13, 15, 17. El guion `-` introduce rangos: `9-17` cubre de 9 AM a 5 PM inclusive en el campo de hora. La coma `,` introduce listas: `1,3,5` en el campo de día de la semana significa lunes, miércoles, viernes. Estos se combinan libremente — `0 9,12,17 * * 1-5` se dispara a las 9 AM, al mediodía y a las 5 PM en días entre semana. Algunas implementaciones de cron agregan especiales adicionales más allá de estos básicos. Quartz (usado por muchas bibliotecas de programación de Java) agrega `L` (último día del mes/semana), `W` (día hábil más cercano) y `#` (n-ésima ocurrencia de un día en un mes). Jenkins agrega `H` para valores hasheados que distribuyen programaciones idénticas a lo largo del tiempo para evitar efectos de estampida. Esta herramienta apunta al formato estándar de 5 campos usado por el crontab de Unix, AWS EventBridge, GCP Cloud Scheduler, Azure Logic Apps y la mayoría de las bibliotecas de programación populares como node-cron y python-crontab.
Detalles Prácticos que Atrapan Incluso a Ingenieros con Experiencia
Varios errores de cron causan repetidamente incidentes de producción incluso para equipos que usan cron todos los días. Primero, el manejo de la zona horaria: las expresiones cron se ejecutan en la zona horaria local del sistema de forma predeterminada, lo que significa que las transiciones de horario de verano en marzo y noviembre pueden hacer que los trabajos se salten un día o se ejecuten dos veces dependiendo de la dirección de la transición. Configure siempre los trabajos cron para que se ejecuten en UTC cuando sea posible, o pruebe explícitamente la transición de horario de verano los fines de semana antes de implementar programaciones urgentes. En segundo lugar, la lógica OR de día del mes versus día de la semana analizada anteriormente capta a los ingenieros que esperan la lógica AND. Si desea que un trabajo se ejecute solo los viernes que caen el día 15, no puede expresarlo en un cron estándar; debe usar la lógica AND en el código de la aplicación después de que se active el trabajo. En tercer lugar, casos extremos de años bisiestos: `0 0 29 2 *` se ejecuta solo el 29 de febrero, lo que ocurre una vez cada 4 años. Probar esto una vez y ver que parece que no funciona es fácil. Cuarto, `@reboot` y otros especiales como `@daily` o `@hourly` son compatibles con muchas implementaciones pero no son portátiles; los programadores de la nube generalmente no los aceptan. Utilice siempre el formulario explícito de 5 campos para la portabilidad. En quinto lugar, los trabajos de ejecución prolongada pueden superponerse: si un trabajo se ejecuta cada 5 minutos pero tarda 7 minutos en ejecutarse, se ejecutarán dos instancias simultáneamente. Ajuste con un archivo de bloqueo (`flock` en Linux) o use la coordinación a nivel de aplicación para evitar esto.