Una expresión cron es una forma compacta de describir el horario de ejecución recurrente de una tarea, usada en sistemas tipo Unix desde los años 70. Cinco campos separados por espacios son capaces de expresar prácticamente cualquier horario regular.
Los cinco campos de la expresión
Una expresión cron estándar tiene la forma minuto hora día-del-mes mes día-de-la-semana. Por ejemplo, 30 14 * * 1 significa "a las 14:30 cada lunes" — los asteriscos significan "cualquier valor" para el día del mes y el mes.
El significado de las barras y las comas
Una barra después de un asterisco, como en */15 * * * *, significa "cada 15 unidades" — en este caso, cada 15 minutos. Una coma permite enumerar varios valores concretos; por ejemplo, 0 9,18 * * * ejecuta la tarea dos veces al día: a las 9:00 y a las 18:00.
Por qué el campo "día de la semana" confunde más
En cron estándar, tanto el campo "día del mes" como "día de la semana" pueden especificarse a la vez sin ser un asterisco — en ese caso, la tarea se ejecuta si se cumple al menos una de las dos condiciones (un OR lógico, no un AND), lo cual contradice la expectativa intuitiva de la mayoría.
La misma sintaxis, del crontab al scheduler de Laravel
Laravel, un framework con una comunidad enorme en España y Latinoamérica, permite definir tareas programadas con métodos como ->dailyAt('13:00') en routes/console.php, pero internamente esas llamadas se traducen exactamente a la misma sintaxis cron de cinco campos. Entender la sintaxis cron real ayuda mucho a depurar por qué una tarea programada se ejecutó (o no) a una hora inesperada.
Para qué se necesita esto
- Descifrar la expresión cron de otra persona en la configuración de un servidor o un pipeline de CI/CD.
- Verificar que un horario escrito es correcto antes de desplegarlo en producción.
- Planificar el momento exacto de las próximas ejecuciones de una tarea.
El cambio de horario de verano/invierno y cron
Si el planificador funciona en una zona horaria con cambio de horario de verano/invierno, una tarea programada para una hora inexistente (por ejemplo, las 2:30 en la noche en que se adelantan los relojes) puede no ejecutarse ese día, y una programada para una hora que se repite al atrasar los relojes puede ejecutarse dos veces. Por eso, para tareas críticas suele elegirse un horario fuera de la ventana típica de cambio (por ejemplo, medianoche o entre las 3 y las 4 de la madrugada) o se fija explícitamente la zona horaria UTC.