Crontab Guru

Pega una expresión cron y obtén una explicación campo por campo, en inglés sencillo, de lo que hace. No necesitas recordar el orden de los campos ni consultar los rangos: el guru repasa cada uno de los cinco campos (minuto, hora, día del mes, mes y día de la semana) y lee la expresión de izquierda a derecha. Útil para comprobar una línea de crontab antes de implementarla o para explicar una línea heredada.

Cómo usar el guru

  1. 1

    Pega la expresión

    Copia cualquier expresión cron estándar de 5 campos (por ejemplo `0 9 * * 1-5`) en el campo de texto.

  2. 2

    Pide la explicación

    Pulsa Explain Cron y la herramienta devuelve una descripción línea a línea de cada campo: minuto, hora, día del mes, mes y día de la semana.

  3. 3

    Lee la descripción

    La explicación se genera en inglés, por ejemplo "Minute: every 5 minutes" u "Hour: from 9 through 17."

  4. 4

    Comprueba antes de implementar

    Usa la explicación para confirmar que el horario hace lo que quieres antes de llevarlo a tu crontab, a la configuración de CI o a un manifiesto de Kubernetes.

Hoja de trucos de campos

 ┌───────────── minuto (0-59)
 │ ┌─────────── hora (0-23)
 │ │ ┌───────── día del mes (1-31)
 │ │ │ ┌─────── mes (1-12 o ENE-DIC)
 │ │ │ │ ┌───── día de la semana (0-6 o DOM-SAB; Dom = 0 o 7)
 │ │ │ │ │
 * * * * *

Operadores en las expresiones cron

Operador Significado Ejemplo
* Cada valor * * * * *
, Lista de valores 0,15,30,45
- Rango 9-17
/ Paso (inicio/paso) */5, 0-30/5
L Último (día del mes o último día laborable, Quartz) L, 5L
W Día laborable más cercano 15W (Quartz)
# N-ésimo día laborable del mes 1#3 (Quartz)
? Sin valor específico Solo Quartz

El orden de lectura importa

0 */2 * * 1-5 se lee de izquierda a derecha como: minuto 0, cada 2 horas, cualquier día del mes, cualquier mes, de lunes a viernes. Por costumbre, a veces se leen los campos de derecha a izquierda y eso confunde; empieza siempre por el minuto.

La trampa de “cada X minutos”

*/10 * * * * se activa en el minuto 0, 10, 20, 30, 40, 50, no “cada 10 minutos desde que se creó el trabajo.” Los pasos de cron siempre se miden desde el comienzo del rango del campo. Si despliegas un trabajo a las 12:03, la primera ejecución es a las 12:10, no a las 12:13.

Para trabajos que realmente necesitan “N minutos después de la última ejecución,” usa un programador con un temporizador persistente (temporizadores de systemd con OnUnitActiveSec, o programación a nivel de aplicación con una marca de última ejecución almacenada).

Errores de cron que conviene conocer

  • Día del mes + día de la semana ambos establecidos: la mayoría de las implementaciones de cron lo tratan como comportamiento OR, probablemente no lo que deseas.
  • Paso de 0: */0 es inválido.
  • Rango que se envuelve: 22-2 para horas no funciona en cron clásico; usa 22-23,0-2.
  • 30 de febrero: un horario como 0 0 30 2 * nunca se activa.
  • Ambigüedad de DST: trabajos programados entre las 2 y las 3 de la madrugada pueden activarse dos veces o ninguna en los días de cambio de hora.

Cron vs. programadores modernos

El cron de Unix sigue estando en todas partes, pero para cualquier cosa crítica probablemente quieras:

  • temporizadores de systemd: capturan ejecuciones perdidas, soportan desplazamientos aleatorios y leen de archivos de unidad.
  • Kubernetes CronJob: declarativo, reintentos, consciente de la zona horaria en 1.25+.
  • Airflow / Prefect / Dagster: para trabajos con dependencias, reintentos, backfills y observabilidad.
  • GitHub Actions schedule: cron de 5 campos, solo UTC, intervalo mínimo de 5 minutos, entrega de mejor esfuerzo.

El cron en sí es un gran formato, pero un mal programador para trabajos que no deben perderse.

Preguntas frecuentes

Porque el día de la semana 0 es domingo en cron estándar (y 7 también es domingo, lo que soporta ambas convenciones). El lunes es 1. Quartz numera los días laborables del 1 al 7 con domingo = 1, lo que confunde con frecuencia a quienes cambian entre dialectos.

El cron clásico de Unix se ejecuta en la zona horaria local del servidor, la que diga /etc/timezone. Kubernetes CronJob, GitHub Actions y la mayoría de los programadores en la nube se ejecutan en UTC por defecto. Confírmalo siempre y, cuando sea posible, usa UTC para evitar sorpresas con el cambio de hora.

El cron clásico no puede expresar esto directamente. Solución alternativa: ejecuta cada lunes y verifica la fecha dentro del script: [ $(date +%d) -le 7 ] && ./job.sh. Quartz lo soporta de forma nativa con 1#1.

No. Cada programación necesita su propia línea. Pero puedes combinar varias programaciones en una línea con listas: 0 9,17 * * * se ejecuta a las 9 y a las 17. Para programaciones que no pueden expresarse en una sola línea, añade varias líneas que apunten al mismo comando.

Herramientas relacionadas