Generador Crontab y Constructor de Expresiones Cron

¿Qué Es una Expresión Cron?

# Linux crontab entry — runs every 15 minutes
*/15 * * * *  /usr/local/bin/poll-api.sh

# Kubernetes CronJob — weekdays at 9:00 AM UTC
apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-report
spec:
  schedule: "0 9 * * 1-5"
  timeZone: "UTC"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: report
              image: report-runner:1.0
          restartPolicy: OnFailure

# GitHub Actions workflow — hourly
on:
  schedule:
    - cron: '0 * * * *'

# AWS EventBridge — first of each month
ScheduleExpression: cron(0 0 1 * ? *)
# (Note: AWS uses the Quartz 6-field form with '?' for day-of-week)

Características Clave

Variantes de Cron y Schedulers

Ejemplos de Expresiones Cron

*/15 * * * *

0 9 * * 1-5

0 0 1 * *

*/5 9-17 * * 1-5

0 0 1 JAN,APR,JUL,OCT *

0 0 1 * 5

30 2 * * *

@daily

Cómo Construir una Expresión Cron

1. 1

   Escribe o pega una expresión cron

   Introduce una expresión cron de cinco campos en el input de arriba (p. ej. `*/15 * * * *`). La herramienta analiza y valida mientras escribes: check verde para válida, error rojo con nombre de campo para inválida. Macros como `@daily`, `@hourly`, etc. también se aceptan.

2. 2

   O ajusta los cinco inputs de campo

   No memorices el orden de los campos: edita Minuto, Hora, Día del mes, Mes o Día de la semana individualmente usando los inputs etiquetados. La expresión completa de arriba se actualiza automáticamente. Usa `*` para comodines, `*/N` para pasos, `a-b` para rangos y `1,3,5` para listas.

3. 3

   Elige un preset para empezar rápido

   Toca cualquier chip preset (Cada 15 minutos, Días laborables a las 9 AM, etc.) para cargar una programación común, y luego ajusta los campos según tu necesidad exacta. Once presets cubren los patrones que realmente usarás en producción.

4. 4

   Verifica la vista previa de próxima ejecución

   Mira las cinco próximas fechas y horas de ejecución; cambia entre Local y UTC para confirmar que la programación se dispara cuando pretendes. Es la forma más fiable de detectar la trampa OR día del mes / día de la semana de POSIX antes de que te muerda en producción.

5. 5

   Copia y pega en tu scheduler

   Haz clic en Copiar para tomar la expresión. Pégala en tu crontab, timer de systemd, `cron:` de GitHub Actions, AWS EventBridge, `schedule` de CronJob de Kubernetes o cualquier scheduler compatible con cron. No olvides verificar la zona horaria del scheduler objetivo; mira la sección de Buenas Prácticas más abajo.

Errores Comunes en Cron

# Pretendido: "primer viernes del mes"
0 0 1-7 * 5
# Realmente: se dispara los días 1-7 del mes O cada viernes, ambas condiciones

# Usa wrapper para semántica AND verdadera
0 0 * * 5  [ $(date +\%d) -le 7 ] && /tu-script
# O elimina una condición y acepta la programación más laxa

# Escrito por dev de US East, desplegado a servidor UTC
0 9 * * *  /tu-reporte.sh
# Se dispara a las 9 AM UTC = 4 AM US East, no lo que el dev quería

# Fija zona horaria, o escribe en UTC explícitamente
CRON_TZ=America/New_York
0 9 * * *  /tu-reporte.sh

# Pretendido: cada 15 minutos
15 * * * *
# Realmente: una vez por hora, en el minuto 15 (4 ejecuciones/hora menos de lo pretendido)

# Correcto
*/15 * * * *
# Cada 15 minutos: minuto 0, 15, 30, 45 de cada hora

# Quartz de 6 campos copiado a crontab de Linux
0 0 9 * * 1-5
# Linux lee: minuto=0, hora=0, dom=9, mes=*, dow=1-5
# = medianoche en días 9 en meses coincidentes con días laborables — caos

# POSIX 5 campos, elimina los segundos
0 9 * * 1-5
# = días laborables a las 9:00 AM

# Febrero 30 o 31, nunca se ejecuta
0 0 30 2 *
0 0 31 2 *
# Se analiza pero ninguna programación se dispara nunca

# Usa patrón 'último día laborable de febrero' vía script
0 0 28-29 2 *  [ $(date -d tomorrow +\%m) = 03 ] && /tu-script

# Quartz: 'último viernes del mes', inválido en POSIX
0 0 ? * 6L *

# Enfoque de script wrapper POSIX para último-viernes
0 0 25-31 * 5  /tu-script
# Ejecutar en viernes entre el 25 y el 31 de cualquier mes

Casos de Uso Comunes

Trabajos de Crontab en Linux

Construye y verifica entradas para `/etc/crontab`, `/etc/cron.d/*` o archivos `crontab -e` por usuario. Usa la vista previa de próxima ejecución para confirmar que la programación cae a la hora correcta en la zona horaria configurada de tu servidor antes de guardar.

Programaciones de CronJob de Kubernetes

Genera el campo `spec.schedule` para un CronJob de Kubernetes. Kubernetes 1.27+ también soporta `spec.timeZone`: usa el toggle UTC para diseñar tu programación en UTC y luego configura `timeZone` explícitamente para evitar la hora local del nodo worker.

Workflows Programados de GitHub Actions

Construye la entrada `cron:` bajo `on.schedule`. GitHub Actions corre siempre en UTC: cambia la vista previa a UTC para confirmar tu programación. Evita intervalos menores a 15 minutos; el scheduler de GitHub omite trabajos de intervalo corto bajo carga.

Reglas de AWS EventBridge

Compón la expresión cron para una regla programada de EventBridge. Nota: AWS usa sintaxis Quartz de seis campos con `?` para día de la semana; esta herramienta emite POSIX de cinco campos, que necesitarás convertir prefijando segundos (`0`) y reemplazando el `*` en uno de los campos de día con `?`.

Pipelines Programadas de GitLab CI

Verifica la expresión cron para una pipeline CI programada en GitLab. GitLab usa sintaxis POSIX de cinco campos, lo que esta herramienta emite, y un selector de fecha en UI, pero el formato cron te da control más fino para intervalos no estándar.

Cron Triggers de Cloudflare Workers

Construye la entrada `[triggers.crons]` en `wrangler.toml`. Cloudflare usa sintaxis POSIX de cinco campos. El intervalo mínimo es un minuto; el worker corre en UTC. Usa la vista previa para verificar que el trigger se dispara dentro de tu ventana esperada.

Programaciones node-cron de Node.js

Construye expresiones para la librería `node-cron`, que soporta tanto POSIX de cinco campos como un campo inicial opcional de segundos. Mantente en cinco campos a menos que necesites específicamente precisión sub-minuto: las expresiones de seis campos no se portan al crontab de Linux.

Revisión de Código y Documentación

Pega una expresión cron de un PR o runbook para ver al instante qué hace, sin más adivinanzas con `30 7 * * 1-5` ni sacar una tarjeta de referencia. La descripción en lenguaje natural también es excelente para comentarios inline y archivos README.

Referencia de Sintaxis Cron

Orden de Campos: M H D M W

Minuto (0-59), Hora (0-23), Día del mes (1-31), Mes (1-12), Día de la semana (0-6, 7 también = domingo). Mnemotécnico: "Mi Hora Determina Mi Semana". El campo día de la semana acepta tanto tokens numéricos (0-6) como con nombre (SUN-SAT, sin distinguir mayúsculas).

Operadores

`*` = cualquier valor; `,` = separador de lista (`1,3,5`); `-` = rango (`1-5`); `/` = paso (`*/15`, `5/10`); nombres: JAN-DEC para mes, SUN-SAT para día de la semana (sin distinguir mayúsculas).

Macros (Alias)

`@yearly` = `0 0 1 1 *`; `@annually` = `0 0 1 1 *`; `@monthly` = `0 0 1 * *`; `@weekly` = `0 0 * * 0`; `@daily` = `0 0 * * *`; `@midnight` = `0 0 * * *`; `@hourly` = `0 * * * *`. `@reboot` es una no-programación especial (solo se ejecuta al arrancar) y se rechaza con un error explicativo.

Semántica POSIX de Día (Regla OR)

Cuando AMBOS día del mes y día de la semana están restringidos (ninguno es `*`), la programación se ejecuta cuando CUALQUIERA coincide, semántica OR. Cuando solo uno está restringido, ese decide. Cuando ambos son `*`, cualquier día coincide. Esta regla OR aplica a vixie cron, BSD cron y la mayoría de implementaciones POSIX; Quartz usa `?` para desambiguar AND vs OR.

Modo de Seis Campos (Quartz-Lite)

Si tu entrada tiene seis tokens separados por espacio, la herramienta trata el primero como campo de segundos (0-59). Útil para Quartz, `@Scheduled(cron=...)` de Spring y node-cron. NO es portable a crontab de Linux ni schedulers POSIX: tratarían tus segundos como minutos y desplazarían todo una posición.

Anclaje del Operador de Paso

`*/N` está anclado al valor más bajo del campo: `*/15` en minuto = `0,15,30,45`, no "cada 15 empezando ahora". Con una base no comodín: `5/15` en minuto = `5,20,35,50`. Los valores de paso que no dividen el rango del campo exactamente saltarán cerca del wraparound: esto es correcto, no un bug.

Límites de Validación

minuto ∈ [0,59], hora ∈ [0,23], día del mes ∈ [1,31], mes ∈ [1,12], día de la semana ∈ [0,7]. Los valores fuera de rango producen un error a nivel de campo. El día del mes NO se valida contra el mes (`0 0 31 2 *` se analiza bien pero nunca coincide porque febrero no tiene día 31; la vista previa de próxima ejecución mostrará "No hay ejecuciones próximas").

Operadores de Quartz Rechazados

Cron POSIX no soporta los operadores de Quartz `?` (sin valor específico), `L` (último), `W` (día laborable más cercano) ni `#` (n-ésimo día de la semana). Esta herramienta los rechaza con un mensaje claro "Operadores de Quartz no soportados" en lugar de analizarlos silenciosamente como POSIX inválido. Para programaciones Quartz, usa una herramienta consciente de Quartz o el scheduler de Spring.

Límite Anual en la Búsqueda de Próxima Ejecución

El cálculo de próxima ejecución busca hasta 4 años hacia adelante; las expresiones que coinciden con menor frecuencia (p. ej. patrones "29 de febrero") mostrarán "No hay ejecuciones próximas en los siguientes 4 años". Es por diseño, para evitar iteración no acotada en patrones imposibles.

Buenas Prácticas para Programaciones Cron

Usa UTC en Servidores, Convierte al Mostrar

Configura tus servidores en UTC (`/etc/timezone` o `TZ=UTC`) y escribe todas las expresiones cron en UTC. Convierte a hora local solo al mostrar en tus dashboards y reportes. Esto elimina toda una categoría de bugs de zona horaria que pegan más fuerte durante las transiciones de horario de verano, cuando las programaciones en hora local se disparan dos veces silenciosamente o saltan una ejecución. Usa el toggle UTC en esta herramienta para diseñar tu programación en UTC desde el principio.

Evita la Trampa POSIX OR de Día del Mes / Día de la Semana

Nunca restrinjas tanto día del mes COMO día de la semana a menos que quieras semántica OR. Si quieres "cada lunes en enero", escribe `0 0 * 1 1` (día del mes es `*`); si quieres "el día 1 de cada mes", escribe `0 0 1 * *` (día de la semana es `*`). La regla POSIX OR significa que `0 0 1 * 1` se ejecuta el día 1 Y cada lunes, casi seguro no es lo que pretendías. La vista previa de próxima ejecución detectará esto si revisas antes de desplegar.

Fija la Zona Horaria de la Programación Explícitamente

Los schedulers modernos soportan fijar la zona horaria en la definición de la programación: `CRON_TZ=America/New_York` al inicio de un crontab (vixie cron 3.0+), `spec.timeZone: "America/New_York"` para CronJobs de Kubernetes 1.27+, expresión de programación con `ScheduleExpressionTimezone` para AWS EventBridge Scheduler. Fija la zona horaria explícitamente en lugar de depender del default del servidor: las zonas horarias del servidor pueden cambiar sin aviso durante migraciones de infraestructura.

Distribuye la Carga Entre Minutos, No en :00

Evita `0 * * * *` (cada hora en el minuto 0) para trabajos no críticos: a escala, programar muchas cosas exactamente en :00 crea picos de carga. Elige un desplazamiento de minuto aleatorio (`23 * * * *`, `41 * * * *`) para cada trabajo para distribuir la carga. Lo mismo aplica para trabajos diarios: `30 3 * * *` es más amigable con tu base de datos que `0 3 * * *` cuando muchos trabajos convergen a las 3:00.

Haz los Trabajos Idempotentes

Cron no tiene reintento integrado, ni prevención de superposición, ni recuperación de ejecuciones perdidas. Tu trabajo debe ser seguro de ejecutar múltiples veces (idempotente) y auto-verificable. En lugar de "enviar reporte a las 9 AM", diséñalo como "enviar el reporte de hoy si aún no se ha enviado": esto se auto-repara tras caídas, programaciones duplicadas accidentales y ejecuciones concurrentes. La idempotencia es una propiedad del trabajo, no del scheduler, y es la práctica de fiabilidad más importante.

Añade un Heartbeat para Programaciones Críticas

El modo de fallo silencioso de cron es su mayor debilidad: si la programación no se dispara, nada te lo dice. Para trabajos críticos, haz que el trabajo haga ping a un servicio de heartbeat (Healthchecks.io, Cronitor, Dead Man's Snitch) al final de cada ejecución; el servicio te alerta si el ping esperado no llega. Esto detecta tanto que el trabajo falle como que la propia programación falle. La capa gratuita cubre la mayoría de necesidades personales y de equipos pequeños.

Verifica con la Vista Previa Antes de Desplegar

Antes de desplegar una nueva programación cron, mira las cinco próximas fechas de ejecución en la vista previa de esta herramienta. Alterna entre Local y UTC. Confirma que la programación cae cuando pretendes, no cinco minutos antes, no en el día equivocado, no saltándose el fin de semana que te importaba. La vista previa es la prueba de producción más barata posible.

Preguntas Frecuentes