Crontab Guru

Ściąga z pól

 ┌───────────── minuta (0-59)
 │ ┌─────────── godzina (0-23)
 │ │ ┌───────── dzień miesiąca (1-31)
 │ │ │ ┌─────── miesiąc (1-12 lub JAN-DEC)
 │ │ │ │ ┌───── dzień tygodnia (0-6 lub SUN-SAT; niedziela = 0 lub 7)
 │ │ │ │ │
 * * * * *

Operatory w wyrażeniach cron

Kolejność czytania ma znaczenie

0 */2 * * 1-5 czyta się od lewej do prawej jako: minuta 0, co 2 godziny, dowolny dzień miesiąca, dowolny miesiąc, od poniedziałku do piątku. Z przyzwyczajenia ludzie czasem czytają pola od prawej do lewej i się gubią; zawsze zaczynaj od minuty.

Pułapka „co X minut”

*/10 * * * * uruchamia się w minutach 0, 10, 20, 30, 40 i 50, a nie „co 10 minut od momentu utworzenia zadania”. Krok w cronie zawsze liczy się od początku zakresu danego pola. Jeśli wdrożysz zadanie o 12:03, pierwsze uruchomienie nastąpi o 12:10, a nie o 12:13.

Dla zadań, które naprawdę wymagają „N minut po ostatnim uruchomieniu”, użyj harmonogramu z trwałym licznikiem czasu (timery systemd z OnUnitActiveSec lub harmonogramowanie na poziomie aplikacji z zapisanym znacznikiem czasu ostatniego uruchomienia).

Pułapki cron, które warto znać

• Ustawiony jednocześnie dzień miesiąca i dzień tygodnia: większość implementacji crona traktuje to jako zachowanie LUB, czego najpewniej nie chcesz.
• Krok 0: */0 jest nieprawidłowy.
• Zakres przechodzący przez północ: 22-2 dla godzin nie działa w klasycznym cronie; użyj 22-23,0-2.
• 30 lutego: harmonogram w stylu 0 0 30 2 * nigdy się nie uruchomi.
• Niejednoznaczność czasu letniego (DST): zadania zaplanowane między 2:00 a 3:00 w dni zmiany czasu mogą uruchomić się dwukrotnie albo wcale.

Cron a nowoczesne harmonogramy

Cron z Uniksa jest wciąż wszędzie, ale do czegoś krytycznego prawdopodobnie będziesz potrzebować jednego z tych rozwiązań:

• Timery systemd: nadrabiają pominięte uruchomienia, obsługują losowe przesunięcia i czytają konfigurację z plików jednostek.
• Kubernetes CronJob: deklaratywny, z ponawianiem prób, uwzględnia strefy czasowe w wersji 1.25 i nowszych.
• Airflow / Prefect / Dagster: do zadań z zależnościami, ponawianiem, uzupełnianiem danych (backfill) i obserwowalnością.
• Harmonogram GitHub Actions: cron z 5 polami, tylko UTC, minimalny odstęp 5 minut, dostarczanie na zasadzie best-effort.

Sam cron to świetny format, ale kiepski harmonogram dla zadań, których nie wolno pominąć.