Skip to content

Generator crontab i kreator wyrażeń cron

Buduj, waliduj i dekoduj wyrażenia cron w przeglądarce. Podgląd kolejnych uruchomień w czasie lokalnym lub UTC. Składnia POSIX 5-polowa, presety, opis po polsku. Za darmo, prywatnie, bez rejestracji.

Bez śledzenia Działa w przeglądarce Bezpłatne
Całe parsowanie i obliczanie kolejnych uruchomień odbywa się lokalnie w przeglądarce. Żadne dane nie są wysyłane na żaden serwer.

Pola
Presety

Po polsku

—

Najbliższe 5 zaplanowanych uruchomień

Strefa czasowa dla podglądu kolejnych uruchomień
    Sprawdzono pod kątem zgodności POSIX 5-polowej, poprawności semantyki OR, zakotwiczenia operatora kroku, rozwijania nazwanych tokenów i odrzucania operatorów Quartz z pomocnymi błędami — Zespół inżynierski Go Tools · May 20, 2026

    Czym jest wyrażenie cron?

    Wyrażenie cron to pięciopolowy ciąg znaków definiujący powtarzający się harmonogram. Od lewej do prawej pola to: minuta (0-59), godzina (0-23), dzień miesiąca (1-31), miesiąc (1-12) i dzień tygodnia (0-6, gdzie 0 i 7 oznaczają niedzielę). Każde pole przyjmuje wartość, listę (`1,3,5`), zakres (`1-5`), symbol wieloznaczny (`*` oznaczający dowolną wartość) lub krok (`*/15` oznaczający co 15). Połączenie definiuje dokładnie, kiedy zaplanowane polecenie się uruchomi — `0 9 * * 1-5` na przykład czyta się „o minucie 0, godzinie 9, dowolny dzień miesiąca, dowolny miesiąc, dzień tygodnia od poniedziałku do piątku” — po polsku „dni robocze o 9:00”.

    Cron powstał w Unix Version 7 w 1979 roku, a gramatyka pięciopolowa pozostała zasadniczo niezmieniona od ponad czterech dekad — świadectwo tego, jak dobrze zaprojektowana jest oryginalna składnia. Dziś wyrażenia cron są używane daleko poza plikiem crontab Unix: Kubernetes CronJobs, przepływy GitHub Actions, reguły AWS EventBridge, zaplanowane potoki GitLab CI, Cloudflare Workers Cron Triggers i platformy serverless w każdej chmurze — wszystkie akceptują tę samą gramatykę pięciopolową. Nauczenie się cron raz oznacza wiedzę, jak planować zadania w każdym nowoczesnym kontekście infrastrukturalnym.

    Standard POSIX definiuje pięć operatorów: `*` (dowolna wartość), `,` (lista wartości), `-` (zakres), `/` (krok) oraz nazwane tokeny dla miesięcy (JAN-DEC) i dni tygodnia (SUN-SAT). Większość implementacji rozwija również pięć popularnych skrótów: `@yearly` (`0 0 1 1 *`), `@monthly` (`0 0 1 * *`), `@weekly` (`0 0 * * 0`), `@daily` (`0 0 * * *`) i `@hourly` (`0 * * * *`). Planer Quartz (biblioteka Java) rozszerza to o opcjonalne pole sekund i dodatkowe operatory (`?`, `L`, `W`, `#`) — przydatne, jeśli pracujesz w Java/Spring, ale nieprzenośne do standardowego cron. To narzędzie stosuje standard POSIX pięciu pól, ponieważ jest to dominujący wariant i ten, który serwer Linux, runner GitHub Actions i klaster Kubernetes faktycznie zrozumieją.

    Jeden kaprys POSIX cron zasługuje na szczególną uwagę: gdy zarówno dzień miesiąca, jak i dzień tygodnia są ograniczone (żaden nie jest `*`), harmonogram uruchamia się, gdy DOWOLNE z nich pasuje — semantyka OR, nie AND. Więc `0 0 1 * 5` uruchamia się 1. każdego miesiąca ORAZ w każdy piątek, a nie tylko w piątki przypadające na 1. To najczęstsza niespodzianka cron; podgląd kolejnych uruchomień w tym narzędziu czyni to oczywistym, pokazując rzeczywiste daty i godziny, kiedy harmonogram się uruchomi. Zweryfikuj przed wdrożeniem.

    Całe parsowanie i obliczanie kolejnych uruchomień odbywa się całkowicie w przeglądarce, używając JavaScript — żadne wyrażenia, harmonogramy ani inne dane nie są nigdy wysyłane na serwer. To narzędzie natychmiast parsuje dowolne standardowe wyrażenie cron POSIX z opisem po polsku i podglądem pięciu uruchomień, przy zachowaniu pełnej prywatności.

    Wyrażenia cron są ściśle powiązane z innymi narzędziami deweloperskimi. Zadania cron są często debugowane przez sprawdzanie Unix timestamp względem oczekiwanych czasów uruchomień, a złożone harmonogramy są często dokumentowane jako konfiguracja JSON, którą można zwalidować naszym formatowaniem JSON. Aby uzyskać dogłębny przewodnik obejmujący semantykę OR, pułapki stref czasowych i popularne warianty cron z przykładami w Linux, Kubernetes i GitHub Actions, przeczytaj naszą referencję harmonogramów 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

    Parser POSIX 5-polowy na żywo

    Ścisły parser zgodny z POSIX cron: 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, gdzie 7 również oznacza niedzielę). Obsługiwane wszystkie standardowe operatory (`*` `,` `-` `/`) i makra (`@yearly` `@monthly` `@weekly` `@daily` `@hourly`).

    Podgląd następnych 5 uruchomień

    Oblicza najbliższe pięć zaplanowanych uruchomień od bieżącego czasu lokalnego. Przełączaj między czasem lokalnym a UTC jednym kliknięciem — najbardziej niezawodny sposób wychwycenia niespodzianek związanych ze strefą czasową przed wdrożeniem pliku crontab na serwer w innym regionie.

    Opis po polsku

    Każde prawidłowe wyrażenie otrzymuje czytelne wyjaśnienie: „Co 15 minut”, „Dni robocze o 9:00”, „O 02:30 w dniu 1 miesiąca, w styczniu i lipcu”. Ułatwia code review i przekazanie pracy w zespole — koniec z domyślaniem się, co właściwie robi `*/5 9-17 * * 1-5`.

    Komunikaty błędów dla konkretnego pola

    Nieprawidłowe wyrażenia otrzymują natychmiastową czerwoną informację zwrotną z podświetlonym problematycznym polem i konkretnym błędem: „Błąd w minucie: wartość poza zakresem [0, 59]: ”60"". Koniec z cichymi awariami crontab odkrytymi trzy dni później, gdy raport się nie uruchomił.

    Presety dla typowych harmonogramów

    Jedenaście jednoklikowych presetów obejmuje harmonogramy, których faktycznie używasz: co minutę, co 5/15 minut, co godzinę, codziennie o północy lub 9:00, dni robocze o 9:00, tygodniowo w niedzielę/poniedziałek, pierwszy każdego miesiąca i rocznie. Klik, dostroj, wdroż.

    Pola edycji per pozycja

    Nie musisz pamiętać kolejności pięciu pól — pięć małych pól oznaczonych Minuta, Godzina, Dzień miesiąca, Miesiąc, Dzień tygodnia pozwala edytować jedną pozycję na raz bez gubienia wartości i błędnej kolejności. Pełne wyrażenie na górze przebudowuje się automatycznie.

    Semantyka OR w POSIX zrobiona dobrze

    Gdy zarówno dzień miesiąca, jak i dzień tygodnia są ograniczone, reguła OR wchodzi w grę — `0 0 1 * 5` uruchamia się w każdy 1. ORAZ w każdy piątek. Podgląd kolejnych uruchomień czyni to widocznym przed wdrożeniem; koniec z niespodziankami weekendowymi w pagerze.

    100% prywatność w przeglądarce

    Wyrażenia cron — które często ujawniają czasy infrastruktury i wewnętrzne wzorce planowania — nigdy nie opuszczają przeglądarki. Żadne dane nie są wysyłane na żaden serwer, brak logowania, brak analityki. Można to zweryfikować w zakładce Network w przeglądarce. Bezpieczne dla produkcyjnych harmonogramów i systemów wewnętrznych.

    Komunikaty błędów świadome Quartz

    Jeśli wkleisz wyrażenie Quartz z `?` `L` `W` lub `#`, parser wyjaśni „Operatory Quartz nie są obsługiwane — użyj składni POSIX”, więc wiesz, że trzeba przepisać dla cron, zamiast debugować cichą awarię. Harmonogramy Quartz nie działają w cron na Linuksie.

    Warianty cron i planery

    Vixie cron (domyślny w Linuksie)

    5-polowy POSIX

    Domyślny w większości dystrybucji Linuksa. Ścisły POSIX z rozszerzeniem `CRON_TZ=` dla jawnej strefy czasowej. Obowiązuje semantyka OR dla dnia miesiąca / dnia tygodnia. Główny cel tego narzędzia.

    BSD cron

    5-polowy POSIX

    Domyślny w macOS i rodzinie BSD. Zgodny z POSIX z drobnymi różnicami implementacyjnymi w stosunku do vixie cron; większość wyrażeń działa identycznie.

    Timery systemd (OnCalendar)

    specyfikacja kalendarzowa, nie cron

    Alternatywa dla cron w Linuksie opartym na systemd. Używa składni `OnCalendar: 2026-*-* 09:00:00` — bardziej czytelna dla harmonogramów niepowtarzających się, ale niewspółpracująca z wyrażeniami cron.

    Quartz Scheduler (Java/Spring)

    6 lub 7 pól

    Dodaje pole sekund (obowiązkowe) i pole roku (opcjonalne) oraz operatory `?`, `L`, `W`, `#`. Przydatny dla aplikacji Java, ale nieprzenośny do cron na Linuksie.

    AWS EventBridge

    6-polowy w stylu Quartz z `?`

    Wymaga, aby dzień tygodnia lub dzień miesiąca były `?` (konwencja Quartz) zamiast `*`, gdy ograniczone jest tylko jedno. Wyrażenia nie przenoszą się bezpośrednio do cron na Linuksie.

    Kubernetes CronJob

    5-polowy POSIX + pole timeZone

    Pięciopolowy harmonogram POSIX plus pole `spec.timeZone` (1.27+). Czystszy niż poleganie na strefie czasowej hosta kubeleta. Wyrażenia przenoszą się bezpośrednio z cron w Linuksie.

    GitHub Actions

    5-polowy POSIX

    Zawsze działa w UTC. Taktowanie na zasadzie najlepszych starań — może być pomijane pod dużym obciążeniem. Unikaj interwałów krótszych niż 15 minut. Wyrażenia przenoszą się bezpośrednio z cron w Linuksie.

    Przykłady wyrażeń cron

    Co 15 minut

    */15 * * * *

    Operator kroku: `*/15` w polu minuty oznacza „co 15 minut, począwszy od minuty 0” — czyli uruchomienia o :00, :15, :30, :45 w każdej godzinie każdego dnia. Najczęstszy interwał do odpytywania API, odświeżania cache i kontroli heartbeat.

    Dni robocze o 9:00

    0 9 * * 1-5

    Zakres `1-5` w polu dnia tygodnia oznacza poniedziałek-piątek (1=pon, 5=pią). Uruchamia się dokładnie o 09:00 — przydatne do raportów godzin pracy, zadań wsadowych zależnych od danych nocnych i przypomnień o codziennym standupie.

    Pierwszy dzień miesiąca o północy

    0 0 1 * *

    Dzień miesiąca `1`, wszystkie pozostałe niższe pola zerowe. Powszechne dla miesięcznych rozliczeń, rotacji logów i uzgodnień końcowych okresu. Dzień miesiąca i dzień tygodnia są oba ograniczone tylko wtedy, gdy żaden nie jest `*` — tutaj dzień tygodnia to `*`, więc liczy się tylko dzień miesiąca.

    Co 5 minut między 9:00 a 17:00, dni robocze

    */5 9-17 * * 1-5

    Łączy krok (`*/5`) z zakresem (`9-17`) w różnych polach. Przydatne do monitoringu wyłącznie w godzinach pracy lub do opróżniania kolejek. Łącznie: 12 uruchomień/godz × 9 godz × 5 dni = 540 uruchomień na tydzień pracy.

    Kwartalnie: 1. stycznia, kwietnia, lipca, października o północy

    0 0 1 JAN,APR,JUL,OCT *

    Nazwy miesięcy na liście rozdzielonej przecinkami. Harmonogramy kwartalne, takie jak zamknięcie finansowe, przeglądy code freeze lub audyty zgodności. Można mieszać nazwy i liczby (`1,APR,7,10` parsuje się tak samo), ale dla czytelności warto trzymać się jednego stylu.

    Pułapka OR w POSIX: 1. dzień miesiąca LUB każdy piątek

    0 0 1 * 5

    Gdy OBA pola — dzień miesiąca (`1`) ORAZ dzień tygodnia (`5`) — są ograniczone, POSIX cron uruchamia zadanie, jeśli DOWOLNE z nich pasuje. Więc to uruchamia się 1. każdego miesiąca ORAZ w każdy piątek — nie tylko w piątki przypadające na 1. To najczęstsza niespodzianka cron; podgląd kolejnych uruchomień czyni to oczywistym.

    Codziennie o 02:30 (okno niskiego ruchu)

    30 2 * * *

    Konkretne wartości dla godziny i minuty, symbole wieloznaczne w pozostałych polach. Okno 02:00-04:00 UTC to faktyczna konwencja dla nocnych zadań wsadowych, ponieważ nie pokrywa się z godzinami pracy żadnego dużego regionu biznesowego. Połącz z przełącznikiem strefy UTC, aby potwierdzić, że uruchomienie wypada tam, gdzie oczekujesz.

    Odpowiednik makra: @daily

    @daily

    Skrót `@daily` (również `@midnight`) rozwija się do `0 0 * * *` — codziennie o północy. Pozostałe makra: `@yearly` = `0 0 1 1 *`, `@monthly` = `0 0 1 * *`, `@weekly` = `0 0 * * 0`, `@hourly` = `0 * * * *`. Makra są zwięzłe, ale forma pięciopolowa jest bardziej przenośna między planerami (np. niektóre obsługują makra, inne nie).

    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

    Pułapka OR w POSIX: oba pola dnia ograniczone

    Gdy OBA pola — dzień miesiąca i dzień tygodnia — są ograniczone, POSIX cron uruchamia zadanie, jeśli DOWOLNE pasuje — nie oba. Więc `0 0 1 * 5` wystartuje 1. każdego miesiąca ORAZ w każdy piątek, a nie tylko w piątki przypadające na 1. Użyj `*` w jednym z dwóch pól dnia, gdy chcesz pojedynczego warunku, lub napisz skrypt wrapper, który robi sprawdzenie AND.

    ✗ Niepoprawne 
    # 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
    ✓ Poprawne 
    # 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

    Rozjazd stref czasowych między dev a prod

    Harmonogramy cron na serwerze Linux używają strefy czasowej systemu, nie strefy lokalnej autora. Cron o 9:00 na serwerze ustawionym na UTC wystartuje o 4:00 rano czasu US East. Zawsze projektuj harmonogramy względem strefy czasowej docelowego serwera — najlepiej UTC — i przypinaj strefę jawnie przez `CRON_TZ=...` na początku pliku crontab.

    ✗ Niepoprawne 
    # 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
    ✓ Poprawne 
    # Przypnij strefę czasową lub napisz wprost w UTC
CRON_TZ=America/New_York
0 9 * * *  /twoj-raport.sh

    Pomylenie operatora kroku: '*/15' vs '15'

    `*/15` w minucie oznacza „co 15 minut, począwszy od 0” (czyli 0, 15, 30, 45). Samo `15` oznacza „tylko o minucie 15” — jedno uruchomienie na godzinę. Początkujący często piszą `15`, myśląc, że to co 15 minut; opis po polsku w narzędziu czyni błąd oczywistym przed wdrożeniem.

    ✗ Niepoprawne 
    # Zamiar: co 15 minut
15 * * * *
# W rzeczywistości: raz na godzinę, o minucie 15 (4 uruchomienia/godz mniej niż zamierzono)
    ✓ Poprawne 
    # Poprawnie
*/15 * * * *
# Co 15 minut: minuta 0, 15, 30, 45 każdej godziny

    Wyrażenie sześciopolowe na planerze POSIX

    Quartz/Spring/node-cron obsługują opcjonalne pole sekund jako pierwszą pozycję. Crontab w Linuksie, GitHub Actions, AWS EventBridge (głównie) i Kubernetes CronJob NIE — oczekują pięciu pól. Wklejenie wyrażenia sześciopolowego cicho psuje harmonogram: sekundy stają się minutami, minuty stają się godzinami itd.

    ✗ Niepoprawne 
    # 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
    ✓ Poprawne 
    # POSIX 5-polowy, porzuć sekundy
0 9 * * 1-5
# = dni robocze o 9:00

    Dzień miesiąca poza zakresem dla miesiąca

    Cron nie waliduje dnia miesiąca względem rzeczywistego miesiąca. `0 0 31 2 *` (31 lutego) parsuje się dobrze, ale nigdy nie pasuje — luty ma co najwyżej 29 dni. Początkujący zakładają, że parser to wychwyci; nie wychwyci. Podgląd kolejnych uruchomień w tym narzędziu pokazuje „Brak nadchodzących uruchomień”, gdy wyrażenie jest strukturalnie prawidłowe, ale logicznie niemożliwe.

    ✗ Niepoprawne 
    # 30 lub 31 lutego — nigdy nie uruchamia
0 0 30 2 *
0 0 31 2 *
# Parsuje, ale żaden harmonogram nigdy nie wystartuje
    ✓ Poprawne 
    # Użyj wzorca „ostatni dzień roboczy lutego” przez skrypt
0 0 28-29 2 *  [ $(date -d tomorrow +\%m) = 03 ] && /twoj-skrypt

    Mylenie składni Quartz z POSIX

    Dokumentacja AWS, tutoriale Spring i wiele odpowiedzi na Stack Overflow pokazują wyrażenia cron Quartz z `?`, `L`, `W` lub `#`. Te nie działają w crontab w Linuksie. Jeśli skopiujesz wyrażenie sześciopolowe z `?` w slocie dnia tygodnia, parser Linux odrzuci je (lub gorzej, cicho błędnie sparsuje). To narzędzie wychwytuje operatory Quartz i wyjaśnia różnicę.

    ✗ Niepoprawne 
    # Quartz: „ostatni piątek miesiąca” — nieprawidłowe w POSIX
0 0 ? * 6L *
    ✓ Poprawne 
    # 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

    Co robi to narzędzie?
    Parsuje, waliduje i wyjaśnia wyrażenia cron w przeglądarce, wraz z podglądem najbliższych pięciu zaplanowanych uruchomień w wybranej strefie czasowej lub UTC. Wpisz dowolne standardowe pięciopolowe wyrażenie cron POSIX — lub użyj presetów i pól indywidualnych, aby zbudować je bez zapamiętywania składni — a narzędzie utworzy opis po polsku („Co 15 minut”, „Dni robocze o 9:00” itd.) oraz rzeczywiste daty i godziny, kiedy zadanie wystartuje. Błędne wyrażenia są wychwytywane natychmiast komunikatem błędu dla konkretnego pola, więc nie tracisz wdrożenia na uszkodzony harmonogram. Całe narzędzie działa w 100% po stronie klienta: nic nie jest przesyłane, logowane ani zapisywane — bezpieczne dla produkcyjnych plików crontab i wewnętrznych harmonogramów z wrażliwymi wzorcami czasowymi.
    Czym jest wyrażenie cron?
    Wyrażenie cron to pięciopolowy ciąg znaków definiujący powtarzający się harmonogram. Pola to: minuta (0-59), godzina (0-23), dzień miesiąca (1-31), miesiąc (1-12) i dzień tygodnia (0-6, gdzie 0 i 7 oznaczają niedzielę). Każde pole przyjmuje wartość, listę (`1,3,5`), zakres (`1-5`), symbol wieloznaczny (`*` = dowolny) lub krok (`*/15` = co 15). Połączenie wszystkich pięciu pól dokładnie określa, kiedy zaplanowane polecenie powinno się uruchomić. Cron powstał w Unix V7 (1979) i pozostaje faktycznym językiem do planowania zadań opartych na czasie w Linux/Unix, w orkiestracji kontenerów (Kubernetes CronJobs), w CI/CD (GitHub Actions, GitLab CI) oraz na platformach serverless (AWS EventBridge, Cloudflare Workers Cron Triggers). Mimo wielu alternatyw proponowanych przez dekady, żaden zamiennik nie wyparł zwięzłej, ekspresyjnej pięciopolowej gramatyki cron.
    Czy dane są gdzieś przesyłane?
    Nie. Całe parsowanie, walidacja i obliczanie kolejnych uruchomień działa w 100% po stronie klienta w przeglądarce, używając JavaScript. Wyrażenia nigdy nie są przesyłane, nigdy nie są przechowywane na żadnym serwerze, nigdy nie są logowane i nigdy nie są analizowane. Dzięki temu narzędzie jest bezpieczne dla produkcyjnych plików crontab, wewnętrznych wzorców planowania, które ujawniają czasy infrastruktury, oraz wszelkich wrażliwych harmonogramów. Można to zweryfikować w zakładce Network w przeglądarce — wpisanie wyrażenia cron nie wywołuje żadnych żądań sieciowych. Narzędzie nie używa plików cookie do danych wejściowych ani analityki zewnętrznej, która rejestrowałaby to, co piszesz.
    Jaka jest różnica między POSIX cron a Quartz?
    POSIX cron to pięciopolowy standard używany przez crontab Unix/Linux, timery systemd, GitHub Actions, GitLab CI, AWS EventBridge, Kubernetes CronJobs i większość planerów. Quartz to biblioteka planowania Java, która dodaje pole sekund (łącznie sześć lub siedem pól) oraz dodatkowe operatory: `?` (brak konkretnej wartości, używane gdy dzień miesiąca i dzień tygodnia są sprzeczne), `L` (last — ostatni dzień miesiąca, ostatni piątek itd.), `W` (najbliższy dzień roboczy) i `#` (n-ty dzień tygodnia w miesiącu, np. `2#1` = pierwszy wtorek). To narzędzie implementuje POSIX cron, ponieważ jest on znacznie szerzej używany; operatory Quartz są zgłaszane jako błędy składni z czytelnym komunikatem „Operatory Quartz nie są obsługiwane”. Jeśli potrzebujesz Quartz, popularne planery Java jak Quartz Scheduler i Spring `@Scheduled` są twoim celem — ale definicje harmonogramów nie przenoszą się bezpośrednio do cron na Linuksie.
    Dlaczego '0 0 1 * 5' uruchamia się w każdy piątek ORAZ 1. dnia miesiąca?
    To semantyka OR (LUB) POSIX cron dla dnia miesiąca / dnia tygodnia i jest to najczęstsza niespodzianka cron. Reguła: gdy OBA pola są ograniczone (żadne nie jest `*`), cron uruchamia zadanie, jeśli DOWOLNY warunek pasuje — nie oba. Więc `0 0 1 * 5` (dzień miesiąca=1, dzień tygodnia=5) wystartuje 1. każdego miesiąca ORAZ w każdy piątek, a nie tylko w piątki przypadające na 1. Jeśli chciałbyś tylko drugiego (semantyka AND — piątek-pierwszego), nie da się tego wyrazić w standardowym cron; potrzebny byłby skrypt uruchamiany w każdy piątek LUB 1. dnia, który wcześnie wychodzi na podstawie rzeczywistej daty. Vixie cron (domyślny w GNU/Linux), BSD cron i AWS EventBridge stosują tę regułę OR. Podgląd kolejnych uruchomień w tym narzędziu czyni rzeczywisty harmonogram oczywistym — wklej podejrzane wyrażenia i zweryfikuj przed wdrożeniem.
    Jak uruchomić zadanie co 30 sekund?
    Nie da się tego zrobić w standardowym POSIX cron. Minimalna granularność cron to jedna minuta — najmniejsze pole to minuta (0-59). Dla harmonogramów krótszych niż minuta opcje są następujące: (1) Uruchom dwa zadania w `* * * * *` i `* * * * *` z `sleep 30 &&` przed jednym — niezbyt eleganckie, ale działa dla vixie cron. (2) Użyj planera z obsługą sekund, jak Quartz, Kubernetes CronJob z niestandardowym kontrolerem lub timery systemd z `OnCalendar: *-*-* *:*:00/30`. (3) Uruchom długo działający demon, który śpi 30 sekund między iteracjami — właściwa odpowiedź dla większości potrzeb monitoringu. (4) Przejdź na trigger sterowany zdarzeniami (webhook, kolejka komunikatów), jeśli faktycznie potrzebujesz odpowiedzi w czasie rzeczywistym. Wzorzec cron co 30 sekund prawie zawsze oznacza, że cron jest niewłaściwą abstrakcją.
    Jakiej strefy czasowej używa cron?
    Na serwerze Linux vixie cron używa strefy czasowej systemu — zwykle ustawianej przez `/etc/timezone` lub zmienną środowiskową `TZ`. To częste źródło błędów: cron o 9:00 na serwerze US East wystartuje o 14:00 UTC, ale na serwerze ustawionym na UTC wystartuje o 09:00 UTC (czyli 4:00 rano czasu East). Rozwiązaniem jest albo zawsze ustawianie serwerów na UTC i pisanie wszystkich wyrażeń cron w UTC, albo ustawienie zmiennej `CRON_TZ=America/New_York` na początku pliku crontab, aby jawnie przypiąć strefę czasową (obsługiwane przez vixie cron 3.0+). Zarządzane planery różnią się: GitHub Actions działa zawsze w UTC, AWS EventBridge obsługuje strefę czasową w definicji harmonogramu, Kubernetes CronJob dodał pole `spec.timeZone` w 1.27+. Przełącznik UTC/Lokalny w tym narzędziu pozwala podejrzeć harmonogram w dowolnej strefie czasowej — przełączaj między nimi, aby potwierdzić, że uruchomienie wypada tam, gdzie zamierzałeś.
    Do czego rozwija się '*/15'?
    Operator kroku `*/N` oznacza „co N, począwszy od najniższej prawidłowej wartości pola”. Dla minuty (zakres 0-59) `*/15` rozwija się do `0,15,30,45` — cztery uruchomienia na godzinę co kwadrans. Krok NIE oznacza „co 15 minut od bieżącego czasu”; jest zakotwiczony w wartości początkowej pola. Ta sama logika dla innych pól: `*/2` w godzinie oznacza `0,2,4,...,22` (12 uruchomień); `*/3` w dniu miesiąca oznacza `1,4,7,...,31` (11 uruchomień). Dla bazy kroku innej niż symbol wieloznaczny (np. `5/15`) rozwinięcie zaczyna się od bazy: `5/15` w minucie = `5,20,35,50`. Wartości kroku, które nie dzielą zakresu równomiernie, będą pomijać blisko przejścia — to poprawne zachowanie cron, nie błąd. Podgląd kolejnych uruchomień czyni rzeczywisty harmonogram oczywistym.
    Czy mogę użyć wyrażenia sześciopolowego z sekundami?
    Wyrażenia sześciopolowe z wiodącym polem sekund (zakres 0-59) to rozszerzenie Quartz/Spring/Cron4j, nie POSIX. To narzędzie akceptuje wyrażenia sześciopolowe, gdy wejście ma dokładnie sześć tokenów oddzielonych spacjami — przydatne, jeśli celujesz w Quartz, Spring `@Scheduled(cron=...)` lub biblioteki Node.js takie jak `node-cron`, które obsługują sekundy. Dla standardowych planerów POSIX (Linux crontab, GitHub Actions, AWS EventBridge, Kubernetes CronJob) trzymaj się pięciu pól — dodanie wiodącego pola sekund cicho zepsuje harmonogram (planer zinterpretuje twoją minutę jako sekundy, twoją godzinę jako minutę itd., przesuwając wszystko o jedno). W razie wątpliwości sprawdź dokumentację docelowego planera; jeśli nie mówi wprost „obsługiwany jest format sześciopolowy z sekundami”, użyj pięciu pól.
    Jaki jest maksymalny interwał, który cron może wyrazić?
    Bez stanu zewnętrznego cron może niezawodnie wyrazić maksymalnie raz w roku za pomocą `0 0 D M *` (np. `0 0 1 1 *` = co 1 stycznia o północy). Dla „co dwa lata” lub dłuższych interwałów sam cron nie wystarczy — potrzebne jest zewnętrzne sprawdzenie daty na początku skryptu (np. `[ $(($(date +%Y) % 2)) -eq 0 ] && /twoje-polecenie`, aby uruchamiać w parzyste lata). Dla „co 90 dni” lub innych niedopasowanych interwałów wielodniowych cron również zawodzi: nie ma natywnego operatora modulo dla dni, więc trzeba napisać wrapper, który sprawdza dzień roku względem daty referencyjnej. Jeśli potrzeby planowania są tak złożone, rozważ prawdziwy planer przepływów (Airflow, Temporal, AWS Step Functions) — gramatyka cron jest celowo prosta i załamuje się dla wszystkiego poza regularnymi wzorcami tygodniowymi/miesięcznymi.
    Jak obsługiwać pominięte uruchomienia po przestoju?
    Standardowy cron nie ma odzyskiwania — jeśli system był wyłączony o zaplanowanej godzinie, uruchomienie jest po prostu pomijane. Nie ma logu „przegapiliśmy to”. Dla zadań krytycznych są trzy opcje: (1) Użyj `anacron` (lub `systemd-cron` z `Persistent=true`), który nadrabia pominięte zadania po starcie systemu, odpowiednie dla laptopów i systemów z przerwami. (2) Przejdź na planer z wbudowanym ponawianiem: Kubernetes CronJobs mają `startingDeadlineSeconds` (uruchom, jeśli opóźnienie mieści się w terminie) i `concurrencyPolicy` (unikaj nakładających się uruchomień); AWS EventBridge obsługuje polityki ponawiania. (3) Wbuduj idempotencję w samo zadanie: zamiast „uruchom raport o 9:00” niech zadanie pyta „czy dzisiejszy raport został już wygenerowany?” i wytwarza go, jeśli nie — to samo-naprawia się po dowolnej długości przestoju. Opcja 3 jest najbardziej niezawodna i działa z dowolnym planerem.
    Dlaczego mój cron w GitHub Actions nie uruchamia się na czas?
    Harmonogramy GitHub Actions działają na zasadzie najlepszych starań: mogą wystartować z kilkuminutowym opóźnieniem przy dużym obciążeniu infrastruktury GitHub, a przy bardzo dużym obciążeniu mogą być całkowicie pominięte (zwłaszcza dla krótkich interwałów jak co pięć minut). To samo zastrzeżenie dotyczy większości zarządzanych planerów — wymieniają dokładne taktowanie na skalowalność i niezawodność. Praktyczne implikacje: (1) Nie planuj rzeczy, które muszą uruchamiać się o dokładnej sekundzie; cron jest do „mniej więcej o tej porze, codziennie”. (2) Dla krótkich interwałów lepiej użyć długo działającego workera niż zaplanowanego zadania. (3) Dla krytycznych pod względem czasu terminów finansowych lub zgodności użyj dedykowanego demona cron na serwerze, który kontrolujesz, lub bardziej rygorystycznego planera, jak AWS EventBridge Scheduler ze standardowym harmonogramem. (4) GitHub Actions konkretnie: unikaj interwałów krótszych niż 15 minut; planer często pomija je pod obciążeniem.

    Powiązane narzędzia

    Zobacz wszystkie narzędzia →

    Konwerter Unix timestamp i epoch — wielokrotna precyzja

    Data i czas

    Błyskawicznie konwertuj Unix timestamp na datę. Automatyczne wykrywanie sekund, milisekund i mikrosekund. Zegar na żywo, dwukierunkowo. Bezpłatnie i prywatnie.

    Konwerter systemów liczbowych — binary, hex, decimal i octal

    Narzędzia konwersji

    Konwertuj między systemami binarnym, szesnastkowym, dziesiętnym i ósemkowym (2–36) w czasie rzeczywistym. Bezpłatnie i prywatnie — w przeglądarce.

    Koder i dekoder Base64

    Kodowanie i formatowanie

    Zakoduj i zdekoduj Base64 online za darmo. Konwersja w czasie rzeczywistym z pełną obsługą UTF-8 i emoji. 100% w przeglądarce, bez rejestracji.

    Konwerter CSV na JSON

    Kodowanie i formatowanie

    Konwertuj CSV na JSON w przeglądarce. RFC 4180, wnioskowanie typów, nagłówek, big-int safe. 100% prywatnie, bez wysyłki.

    Kompresor obrazów online — JPEG, PNG i WebP

    Narzędzia konwersji

    Kompresja JPEG, PNG i WebP nawet o 80% — w przeglądarce, bez przesyłania na serwer. Wsadowo do 20 obrazów, porównanie przed i po. Prywatnie.

    JSON Diff (Porównaj)

    Kodowanie i formatowanie

    Porównaj dwa pliki JSON natychmiast w przeglądarce. Podświetlanie obok siebie, wynik JSON Patch (RFC 6902), ignorowanie szumliwych pól jak znaczniki czasu i identyfikatory. 100% prywatności, bez przesyłania.