*/5 * * * *Felder
| Minute | */5 | 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55 |
|---|---|---|
| Stunde | * | beliebig |
| Tag des Monats | * | beliebig |
| Monat | * | beliebig |
| Wochentag | * | beliebig |
Wo du ihn verwendest
| crontab | */5 * * * * /path/to/script.sh |
|---|---|
| GitHub Actions | - cron: "*/5 * * * *" (on.schedule) |
| Kubernetes CronJob | schedule: "*/5 * * * *" |
crontab läuft in der Zeitzone des Servers; GitHub Actions verwendet immer UTC.
Gut zu wissen
*/5 im Minutenfeld läuft in den Minuten 0, 5, 10 und so weiter bis 55, ausgerichtet an der Uhr, nicht daran, wann du die Crontab gespeichert hast. Jeder Job auf jedem Server mit */5 startet in derselben Sekunde, was eine gemeinsam genutzte Datenbank oder API kurzzeitig überlasten kann; versetze stark belastende Jobs mit 2-59/5, das bei 2, 7, 12 und so weiter läuft. Alle 10 Minuten ist */10.
Wenn ein Lauf länger als 5 Minuten dauern kann, sichere ihn mit flock -n ab, damit sich keine Kopien überlappen; in Kubernetes macht concurrencyPolicy: Forbid dasselbe. PATH und Umgebung von cron sind minimal, also ruf Programme mit absolutem Pfad auf und lade Variablen im Skript. Häng die Ausgabe an ein Log an. GitHub Actions akzeptiert */5 als Minimum, aber geplante Läufe starten unter Last oft einige Minuten zu spät.