¿Qué hace realmente esta expresión cron?

El cron estándar se lee de izquierda a derecha como minuto, hora, día del mes, mes, día de la semana. Algunos planificadores — este incluido — aceptan un campo inicial opcional de segundos, lo que hace seis en total. Cada campo admite un número, una lista separada por comas, un rango (1-5), un paso (*/15) o una combinación (10-50/10). Los campos de mes y de día de la semana aceptan además nombres: JAN-DEC y SUN-SAT (o 0-7, donde tanto 0 como 7 significan domingo).

* significa «cualquier valor» para ese campo — * * * * * se dispara cada minuto. */15 significa «cada 15.º valor a partir del mínimo del campo»: para los minutos, eso es :00, :15, :30 y :45.

El cron de toda la vida — el de tu crontab — son 5 campos, con un suelo de una ejecución por minuto. Algunas herramientas (esta, y cosas como node-cron) aceptan un sexto campo inicial para los segundos, que es la única forma de expresar «cada 10 segundos» en sintaxis cron. Los dos formatos se confunden con facilidad: 0 30 2 * * * parece que podría significar las 2:30, pero con seis campos el primer 0 son los segundos y la programación se dispara en realidad a las 02:30:00 — que, escrita como cron de 5 campos, sería 30 2 * * *. Contar mal los campos es la forma más común de programar la tarea correcta a la hora equivocada.

Los atajos con @ — @hourly, @daily, @weekly, @monthly, @yearly (@annually y @midnight son alias) — se expanden a expresiones fijas de cron estándar y se comportan igual. @reboot es otra cosa; lo vemos más abajo.

0 0 13 * 5 se lee como «el día 13, si cae en viernes» — martes y trece, para entendernos. Pues no. El cron estándar trata el día del mes y el día de la semana como un OR siempre que ambos están restringidos: la tarea se dispara el 13 de cada mes y todos los viernes, lo que en la mayoría de los meses son cinco o seis ejecuciones en lugar de la única que tenías en la cabeza.

Esto solo muerde cuando los dos campos están restringidos a la vez. 0 0 13 * * (todos los días 13, con el día de la semana en *) significa exactamente lo que parece, y 0 0 * * 5 (todos los viernes) también. Es la combinación la que cambia en silencio de AND a OR, y es una de las sorpresas más antiguas de cron: POSIX lo especifica, todas las implementaciones serias lo respetan, y sigue pillando a gente que aprendió a programar después de que se escribieran casi todas las especificaciones POSIX.

Cron programa en hora de reloj, y la hora de reloj no es continua a través de un cambio de horario de verano. Dos veces al año, en algún sitio, un reloj se salta una hora o repite otra — y una tarea programada dentro de esa hora tiene que hacer algo, porque «ejecútala igualmente» no tiene un significado unívoco.

Cuando los relojes se adelantan, las horas de reloj de la hora saltada no existen. Una tarea puesta a las 02:30 el día en que Europe/Paris salta de las 02:00 a las 03:00 sencillamente no tiene ninguna 02:30 en la que ejecutarse — esta herramienta reporta esa ejecución como omitida en lugar de moverla en silencio a las 01:30 o a las 03:30, porque cualquiera de las dos suposiciones sería errónea al menos tan a menudo como acertada.

Cuando los relojes se atrasan, las horas de reloj de la hora repetida ocurren dos veces. Esta herramienta sigue la convención que usan todas las implementaciones de cron que conocemos: disparar una sola vez, en la primera ocurrencia, y no dos.

El arreglo práctico es aburrido pero fiable: programa las tareas de mantenimiento fuera de la franja de 00:00 a 04:00, donde la mayoría de las regiones colocan su cambio de horario, o haz correr toda tu infraestructura en UTC de punta a punta, donde esta sección entera no aplica.

@reboot se ejecuta una vez, al arrancar la máquina — cron no garantiza nada más allá de eso, y no tiene concepto de «próxima ejecución» porque no la hay. Eso lo convierte en mal candidato para el patrón habitual de monitorización, «avísame si esto no se ejecuta según lo programado»: no hay programación, así que no hay nada contra lo que contrastar un silencio. Si una tarea @reboot importa — restaurar estado después de una caída, pongamos — lo que suele merecer vigilancia es el estado que restaura, no el arranque en sí.

¿Hace falta una cuenta?

No. No hay registro ni límite de peticiones digno de mención, porque aquí nada llama a un servidor: tanto el análisis como el cálculo de las próximas ejecuciones ocurren en tu navegador.

¿Guardáis las expresiones que pruebo?

No. Nada de lo que escribes se envía a ninguna parte, así que no hay nada que guardar ni nada que puedas pedirnos que borremos.

¿Por qué a veces muestra menos de 8 ejecuciones?

Un puñado de expresiones describe una programación que se dispara rara vez, o nunca. 0 0 31 2 * (31 de febrero) no coincide con ninguna fecha real y devuelve cero ejecuciones. 0 0 29 2 * (29 de febrero) solo coincide en años bisiestos, así que puede hacer falta buscar durante varios años hasta que aparezca la siguiente.

¿Qué extensiones de cron no admite?

Los extras al estilo Quartz que algunos planificadores añaden encima del cron POSIX: L (último día), W (día laborable más cercano), # (enésimo día de la semana del mes) y ? (sin valor concreto). Esta herramienta los señala de forma explícita en lugar de malinterpretarlos en silencio como otra cosa.

Mi servidor usa una zona horaria distinta de la que he elegido aquí, ¿eso importa?

Sí, y conviene comprobarlo. En una máquina Linux típica, cron corre en la zona horaria configurada en el sistema, que no tiene por qué ser UTC ni la tuya. Elige la zona en la que se ejecuta realmente la crontab de tu tarea, no la zona en la que estás sentado tú, o las horas que muestra esta herramienta no coincidirán con la realidad.