Generator crontab i kreator wyrażeń cron

Czym jest wyrażenie 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)

Kluczowe funkcje

Warianty cron i planery

Przykłady wyrażeń 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

Jak zbudować wyrażenie cron

1. 1

   Wpisz lub wklej wyrażenie cron

   Wprowadź pięciopolowe wyrażenie cron w polu powyżej (np. */15 * * * *). Narzędzie parsuje i waliduje w czasie pisania — zielony znacznik dla prawidłowego, czerwony błąd z nazwą pola dla nieprawidłowego. Makra typu @daily, @hourly itd. są również akceptowane.

2. 2

   Lub dostosuj pięć pól

   Nie musisz pamiętać kolejności pól — edytuj Minutę, Godzinę, Dzień miesiąca, Miesiąc lub Dzień tygodnia indywidualnie przy użyciu oznaczonych pól. Pełne wyrażenie na górze aktualizuje się automatycznie. Użyj * dla symboli wieloznacznych, */N dla kroków, a-b dla zakresów i 1,3,5 dla list.

3. 3

   Wybierz preset, aby szybko zacząć

   Kliknij dowolny preset (Co 15 minut, Dni robocze o 9:00 itd.), aby wczytać typowy harmonogram, a następnie dostosuj pola do dokładnych potrzeb. Jedenaście presetów obejmuje wzorce, których faktycznie używasz na produkcji.

4. 4

   Zweryfikuj podgląd kolejnych uruchomień

   Spójrz na pięć nadchodzących dat i godzin uruchomień — przełączaj między czasem lokalnym a UTC, aby potwierdzić, że harmonogram uruchamia się wtedy, kiedy zamierzasz. To najbardziej niezawodny sposób wychwycenia pułapki OR dnia miesiąca / dnia tygodnia w POSIX, zanim ugryzie cię na produkcji.

5. 5

   Skopiuj i wklej do planera

   Kliknij Kopiuj, aby pobrać wyrażenie. Wklej do pliku crontab, timera systemd, cron: w GitHub Actions, AWS EventBridge, schedule w Kubernetes CronJob lub dowolnego planera zgodnego z cron. Nie zapomnij zweryfikować strefy czasowej docelowego planera — zobacz sekcję Najlepsze praktyki poniżej.

Częste błędy cron

# Zamiar: „pierwszy piątek miesiąca”
0 0 1-7 * 5
# W rzeczywistości: uruchamia się 1-7 dnia miesiąca LUB w każdy piątek — oba warunki

# Użyj wrappera dla prawdziwej semantyki AND
0 0 * * 5  [ $(date +\%d) -le 7 ] && /twoj-skrypt
# LUB porzuć jeden warunek i zaakceptuj luźniejszy harmonogram

# Napisane przez deva z US East, wdrożone na serwer UTC
0 9 * * *  /twoj-raport.sh
# Wystartuje o 9 UTC = 4 rano US East — nie to, co dev miał na myśli

# Przypnij strefę czasową lub napisz wprost w UTC
CRON_TZ=America/New_York
0 9 * * *  /twoj-raport.sh

# Zamiar: co 15 minut
15 * * * *
# W rzeczywistości: raz na godzinę, o minucie 15 (4 uruchomienia/godz mniej niż zamierzono)

# Poprawnie
*/15 * * * *
# Co 15 minut: minuta 0, 15, 30, 45 każdej godziny

# 6-polowy Quartz skopiowany do crontab w Linuksie
0 0 9 * * 1-5
# Linux czyta: minuta=0, godzina=0, dzień miesiąca=9, miesiąc=*, dzień tyg=1-5
# = północ w dniach 9 w miesiącach pasujących do dni roboczych — chaos

# POSIX 5-polowy, porzuć sekundy
0 9 * * 1-5
# = dni robocze o 9:00

# 30 lub 31 lutego — nigdy nie uruchamia
0 0 30 2 *
0 0 31 2 *
# Parsuje, ale żaden harmonogram nigdy nie wystartuje

# Użyj wzorca „ostatni dzień roboczy lutego” przez skrypt
0 0 28-29 2 *  [ $(date -d tomorrow +\%m) = 03 ] && /twoj-skrypt

# Quartz: „ostatni piątek miesiąca” — nieprawidłowe w POSIX
0 0 ? * 6L *

# Wzorzec wrappera POSIX dla ostatniego piątku
0 0 25-31 * 5  /twoj-skrypt
# Uruchamia w piątek między 25. a 31. dowolnego miesiąca

Typowe zastosowania

Zadania crontab w Linuksie

Buduj i weryfikuj wpisy dla /etc/crontab, /etc/cron.d/* lub plików crontab -e dla użytkownika. Użyj podglądu kolejnych uruchomień, aby potwierdzić, że harmonogram trafia we właściwy czas w skonfigurowanej strefie czasowej serwera, zanim zapiszesz.

Harmonogramy Kubernetes CronJob

Generuj pole spec.schedule dla Kubernetes CronJob. Kubernetes 1.27+ obsługuje również spec.timeZone — użyj przełącznika UTC, aby zaprojektować harmonogram w UTC, a następnie jawnie ustaw timeZone, aby uniknąć czasu lokalnego węzła workera.

Zaplanowane przepływy GitHub Actions

Buduj wpis cron: w on.schedule. GitHub Actions zawsze działa w UTC — przełącz podgląd na UTC, aby potwierdzić harmonogram. Unikaj interwałów krótszych niż 15 minut; planer GitHub pomija zadania o krótkich interwałach pod obciążeniem.

Reguły AWS EventBridge

Twórz wyrażenie cron dla zaplanowanej reguły EventBridge. Uwaga: AWS używa składni sześciopolowej w stylu Quartz z ? dla dnia tygodnia — to narzędzie emituje POSIX pięciopolowy, który trzeba przekonwertować, dodając prefiks sekund (0) i zastępując * w jednym z pól dnia znakiem ?.

Zaplanowane potoki GitLab CI

Weryfikuj wyrażenie cron dla zaplanowanego potoku CI w GitLab. GitLab używa pięciopolowej składni POSIX — tej, którą emituje to narzędzie — oraz selektora dat w UI, ale forma cron daje dokładniejszą kontrolę dla niestandardowych interwałów.

Cloudflare Workers Cron Triggers

Buduj wpis [triggers.crons] w wrangler.toml. Cloudflare używa pięciopolowej składni POSIX. Minimalny interwał to jedna minuta; worker działa w UTC. Użyj podglądu, aby zweryfikować, że trigger uruchamia się w oczekiwanym oknie.

Harmonogramy Node.js node-cron

Buduj wyrażenia dla biblioteki node-cron, która obsługuje zarówno pięciopolowy POSIX, jak i opcjonalne wiodące pole sekund. Trzymaj się pięciu pól, chyba że konkretnie potrzebujesz precyzji subminutowej — wyrażenia sześciopolowe nie przenoszą się do crontab w Linuksie.

Code review i dokumentacja

Wklej wyrażenie cron z PR lub runbooka, aby natychmiast zobaczyć, co robi — koniec z domyślaniem się przy 30 7 * * 1-5 lub wyciąganiem ściągi. Opis po polsku jest również świetny do komentarzy inline i plików README.

Referencja składni cron

Kolejność pól: M G D M T

Minuta (0-59), Godzina (0-23), Dzień miesiąca (1-31), Miesiąc (1-12), Dzień tygodnia (0-6, 7 również = niedziela). Pole dnia tygodnia akceptuje zarówno tokeny numeryczne (0-6), jak i nazwane (SUN-SAT, niewrażliwe na wielkość liter).

Operatory

* = dowolna wartość; , = separator listy (1,3,5); - = zakres (1-5); / = krok (*/15, 5/10); nazwy: JAN-DEC dla miesiąca, SUN-SAT dla dnia tygodnia (niewrażliwe na wielkość liter).

Makra (aliasy)

@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 to specjalny element niebędący harmonogramem (uruchamia się tylko przy starcie) i jest odrzucany z wyjaśniającym błędem.

Semantyka dni POSIX (reguła OR)

Gdy OBA pola — dzień miesiąca i dzień tygodnia — są ograniczone (żadne nie jest *), harmonogram uruchamia się, gdy DOWOLNE pasuje — semantyka OR. Gdy ograniczone jest tylko jedno, ono decyduje. Gdy oba są *, każdy dzień pasuje. Ta reguła OR obowiązuje w vixie cron, BSD cron i większości implementacji POSIX; Quartz używa ? do rozróżnienia AND vs OR.

Tryb sześciopolowy (Quartz-Lite)

Jeśli wejście ma sześć tokenów oddzielonych spacjami, narzędzie traktuje pierwszy jako pole sekund (0-59). Przydatne dla Quartz, Spring @Scheduled(cron=...) i node-cron. NIEPRZENOŚNE do crontab w Linuksie ani planerów POSIX — potraktują twoje sekundy jako minuty i przesuną wszystko o jedną pozycję.

Zakotwiczenie operatora kroku

*/N jest zakotwiczone do najniższej wartości pola: */15 w minucie = 0,15,30,45, a nie „co 15 począwszy od teraz”. Z bazą inną niż symbol wieloznaczny: 5/15 w minucie = 5,20,35,50. Wartości kroku, które nie dzielą zakresu pola równomiernie, będą pomijać blisko przejścia — to poprawne zachowanie, nie błąd.

Granice walidacji

minuta ∈ [0,59], godzina ∈ [0,23], dzień miesiąca ∈ [1,31], miesiąc ∈ [1,12], dzień tygodnia ∈ [0,7]. Wartości spoza zakresu generują błąd dla konkretnego pola. Dzień miesiąca NIE jest walidowany względem miesiąca (0 0 31 2 * parsuje się dobrze, ale nigdy nie pasuje, bo luty nie ma dnia 31 — podgląd kolejnych uruchomień pokaże „Brak nadchodzących uruchomień”).

Operatory Quartz odrzucane

POSIX cron nie obsługuje operatorów Quartz: ? (brak konkretnej wartości), L (ostatni), W (najbliższy dzień roboczy) ani # (n-ty dzień tygodnia). To narzędzie odrzuca je z czytelnym komunikatem „Operatory Quartz nie są obsługiwane”, zamiast cicho parsować jako nieprawidłowy POSIX. Dla harmonogramów Quartz użyj narzędzia świadomego Quartz lub planera Spring.

Limit roku dla wyszukiwania kolejnych uruchomień

Obliczanie kolejnych uruchomień szuka do 4 lat naprzód; wyrażenia pasujące rzadziej (np. wzorce „29 lutego”) pokażą „Brak nadchodzących uruchomień w ciągu najbliższych 4 lat”. Jest to zaprojektowane celowo, aby uniknąć nieograniczonej iteracji dla niemożliwych wzorców.

Najlepsze praktyki dla harmonogramów cron

Używaj UTC na serwerach, konwertuj w momencie wyświetlania

Ustaw serwery na UTC (/etc/timezone lub TZ=UTC) i pisz wszystkie wyrażenia cron w UTC. Konwertuj na czas lokalny tylko w momencie wyświetlania w dashboardach i raportach. Eliminuje to całą kategorię błędów strefy czasowej, które uderzają najmocniej podczas przejść czasu letniego/zimowego, gdy harmonogramy w czasie lokalnym cicho podwajają uruchomienia lub pomijają jedno. Użyj przełącznika UTC w tym narzędziu, aby projektować harmonogram w UTC od początku.

Unikaj pułapki OR dla dnia miesiąca/dnia tygodnia w POSIX

Nigdy nie ograniczaj jednocześnie dnia miesiąca ORAZ dnia tygodnia, chyba że chcesz semantyki OR. Jeśli chcesz „każdy poniedziałek w styczniu”, napisz 0 0 * 1 1 (dzień miesiąca to *); jeśli chcesz „1. każdego miesiąca”, napisz 0 0 1 * * (dzień tygodnia to *). Reguła OR w POSIX oznacza, że 0 0 1 * 1 uruchamia się 1. ORAZ w każdy poniedziałek — prawie na pewno nie to, co zamierzałeś. Podgląd kolejnych uruchomień wychwyci to, jeśli sprawdzisz przed wdrożeniem.

Jawnie przypnij strefę czasową harmonogramu

Nowoczesne planery obsługują przypinanie strefy czasowej w definicji harmonogramu: CRON_TZ=America/New_York na początku pliku crontab (vixie cron 3.0+), spec.timeZone: "America/New_York" dla Kubernetes CronJobs 1.27+, wyrażenie harmonogramu z ScheduleExpressionTimezone dla AWS EventBridge Scheduler. Przypnij strefę czasową jawnie, zamiast polegać na domyślnej strefie serwera — strefy czasowe serwerów mogą zmieniać się bez ostrzeżenia podczas migracji infrastruktury.

Rozłóż obciążenie na minuty, nie tylko o :00

Unikaj 0 * * * * (co godzinę o minucie 0) dla zadań niekrytycznych — na dużą skalę planowanie wielu rzeczy dokładnie o :00 tworzy skoki obciążenia. Wybierz losowe przesunięcie minuty (23 * * * *, 41 * * * *) dla każdego zadania, aby rozłożyć obciążenie. To samo dotyczy zadań codziennych: 30 3 * * * jest bardziej przyjazne dla bazy danych niż 0 3 * * *, gdy wiele zadań zbiega się o 3:00.

Spraw, aby zadania były idempotentne

Cron nie ma wbudowanych ponawianych prób, zapobiegania nakładaniu, odzyskiwania pominiętych uruchomień. Zadanie powinno być bezpieczne do wielokrotnego uruchamiania (idempotentne) i samosprawdzające. Zamiast „wyślij raport o 9:00”, zaprojektuj je jako „wyślij dzisiejszy raport, jeśli jeszcze nie wysłano” — to samo-naprawia się po przestoju, przypadkowych podwójnych harmonogramach i jednoczesnych uruchomieniach. Idempotencja jest właściwością zadania, nie planera, i jest najważniejszą praktyką niezawodnościową.

Dodaj heartbeat dla krytycznych harmonogramów

Cichy tryb awarii cron to jego największa słabość — jeśli harmonogram się nie uruchomi, nic ci nie powie. Dla zadań krytycznych niech zadanie pinguje usługę heartbeat (Healthchecks.io, Cronitor, Dead Man's Snitch) na końcu każdego uruchomienia; usługa powiadamia cię, jeśli oczekiwany ping nie nadejdzie. Wychwytuje to zarówno awarię zadania, jak i błędne uruchomienie samego harmonogramu. Darmowy plan pokrywa większość potrzeb osobistych i małych zespołów.

Zweryfikuj podglądem kolejnych uruchomień przed wdrożeniem

Przed wdrożeniem nowego harmonogramu cron spójrz na pięć nadchodzących dat i godzin uruchomień w podglądzie tego narzędzia. Przełączaj między czasem lokalnym a UTC. Potwierdź, że harmonogram trafia, kiedy zamierzasz — nie pięć minut wcześniej, nie w niewłaściwy dzień, nie pomijając weekendu, na którym ci zależało. Podgląd to najtańszy możliwy test produkcyjny.

Często zadawane pytania