* * * * *Campos
| Minuto | * | cualquiera |
|---|---|---|
| Hora | * | cualquiera |
| Día del mes | * | cualquiera |
| Mes | * | cualquiera |
| Día de la semana | * | cualquiera |
Dónde usarla
| crontab | * * * * * /path/to/script.sh |
|---|---|
| GitHub Actions | - cron: "* * * * *" (on.schedule) |
| Kubernetes CronJob | schedule: "* * * * *" |
crontab usa la zona horaria del servidor; GitHub Actions siempre usa UTC.
A tener en cuenta
Cada minuto es la resolución más fina que ofrece el cron estándar; para algo más rápido, usa un bucle dentro del script, una segunda entrada que empiece con sleep 30 o un timer de systemd. El principal problema es el solapamiento: si una ejecución tarda más de un minuto, las copias se acumulan. Envuelve la tarea en flock, por ejemplo flock -n /tmp/job.lock /path/to/script.sh, para que una nueva ejecución termine si la anterior sigue en marcha.
Cron se ejecuta con un entorno mínimo: el PATH suele ser solo /usr/bin:/bin, no se carga ningún perfil de la shell y la carpeta de trabajo es tu carpeta personal, así que usa rutas absolutas. La salida se envía por correo al usuario o se descarta, así que redirígela con >> /var/log/job.log 2>&1 y rota ese log. GitHub Actions no se ejecuta con esta frecuencia: su intervalo mínimo es de 5 minutos. Una alternativa cercana más suave es */2, cada dos minutos.