0 0 * * *Campos
| Minuto | 0 | 0 |
|---|---|---|
| Hora | 0 | 0 |
| Día del mes | * | cualquiera |
| Mes | * | cualquiera |
| Día de la semana | * | cualquiera |
Dónde usarla
| crontab | 0 0 * * * /path/to/script.sh |
|---|---|
| GitHub Actions | - cron: "0 0 * * *" (on.schedule) |
| Kubernetes CronJob | schedule: "0 0 * * *" |
crontab usa la zona horaria del servidor; GitHub Actions siempre usa UTC.
A tener en cuenta
0 0 * * * se ejecuta a las 00:00 en la zona horaria del servidor, que en las máquinas en la nube suele ser UTC y no tu medianoche local; compruébalo con timedatectl. @daily y @midnight son atajos para la misma programación. La medianoche es la opción por defecto de todo el mundo, así que a esa hora las copias de seguridad, los informes y las tareas de otros clientes de la misma máquina compiten por el disco y la base de datos; una franja más tranquila, como 17 0 * * *, suele ser más considerada.
Cron trata un % sin escapar como un salto de línea, así que escápalo dentro del crontab: date -d yesterday +\%F da la fecha que normalmente debería procesar una tarea nocturna. Si el servidor está apagado a medianoche, el cron estándar no recupera la ejecución; anacron o un timer de systemd con Persistent=true sí. Añade un dead man’s switch como Healthchecks.io o Cronitor para enterarte de cuándo la tarea deja de ejecutarse sin avisar.