Zgody cookies i prywatność
Opcjonalny pomiar i usługi Google uruchamiamy tylko po Twojej zgodzie. Panel zgód (CMP) zapisuje wybór; odmowa nie blokuje playgroundów.
Schedule explainer

Wyjasnij cron schedule zanim obudzi produkcje

Wklej 5-polowy albo 6-polowy cron expression, wybierz timezone i zobacz nastepne wystapienia, rozbicie pol oraz kontrolowane diagnostyki parsera. Evaluator dziala lokalnie i nigdy nie uruchamia joba.

  • Bez backend scheduler
  • Timezone i DST caveats
  • Strict mode diagnostics

Prywatna powierzchnia review dla harmonogramow

Cron syntax jest tak zwiezly, ze latwo ukrywa pomylki. Ten playground rozwija minutes, hours, day-of-month, month, day-of-week i opcjonalne seconds do czytelnego review zanim schedule trafi do CI, Kubernetes, Cloud Scheduler albo server crontab.

Strona nie uruchamia jobow, nie wywoluje backendu, nie pobiera project config, nie zapisuje schedules, nie zapisuje URL state i nie wysyla custom analytics payloadow z expression, timezone, data ani occurrence list.

Cron workbench

Zacznij od presetu, edytuj expression i porownaj semantyke pol z nadchodzacymi czasami local oraz UTC.

Clean

Co 15 minut w oknie pracy w dni robocze dla Europe/Warsaw.

Schedule input

Evaluation result

Normalized*/15 9-17 * * 1-5
Next runs8
TimezoneEurope/Warsaw
Duration258 ms

Diagnostics

DST caveat

Local timezone schedules moga pominac albo powtorzyc wall-clock time podczas zmian czasu.

Europe/Warsaw

Field breakdown

Second0

Fixed: uruchamia tylko wtedy, gdy pole ma te wartosc.

Minute*/15

Step: powtarza sie przez pole z ustawionym interwalem.

step
Hour9-17

Range: akceptuje wartosci miedzy dolna i gorna granica.

range
Day of month*

Wildcard: akceptuje kazda wartosc w tym polu.

wildcard
Month*

Wildcard: akceptuje kazda wartosc w tym polu.

wildcard
Day of week1-5

Range: akceptuje wartosci miedzy dolna i gorna granica.

range

Next occurrences

1 8 Jun 2026, 11:15:00 2026-06-08T11:15:00 8 Jun 2026, 09:15:00 2026-06-08T09:15:00.000Z
2 8 Jun 2026, 11:30:00 2026-06-08T11:30:00 8 Jun 2026, 09:30:00 2026-06-08T09:30:00.000Z
3 8 Jun 2026, 11:45:00 2026-06-08T11:45:00 8 Jun 2026, 09:45:00 2026-06-08T09:45:00.000Z
4 8 Jun 2026, 12:00:00 2026-06-08T12:00:00 8 Jun 2026, 10:00:00 2026-06-08T10:00:00.000Z
5 8 Jun 2026, 12:15:00 2026-06-08T12:15:00 8 Jun 2026, 10:15:00 2026-06-08T10:15:00.000Z
6 8 Jun 2026, 12:30:00 2026-06-08T12:30:00 8 Jun 2026, 10:30:00 2026-06-08T10:30:00.000Z
7 8 Jun 2026, 12:45:00 2026-06-08T12:45:00 8 Jun 2026, 10:45:00 2026-06-08T10:45:00.000Z
8 8 Jun 2026, 13:00:00 2026-06-08T13:00:00 8 Jun 2026, 11:00:00 2026-06-08T11:00:00.000Z

Copyable cron-parser snippet

import { CronExpressionParser } from 'cron-parser/dist/CronExpressionParser';

const expression = "*/15 9-17 * * 1-5";
const interval = CronExpressionParser.parse(expression, {
  currentDate: "2026-06-08T09:00:00.000Z",
  tz: "Europe/Warsaw",
  strict: false,
});

const nextRuns = interval.take(8).map((run) => run.toDate().toISOString());
console.log(nextRuns);

Cron review notes

Piec pol i szesc pol oznaczaja co innego

Classic cron uzywa minute, hour, day-of-month, month i day-of-week. Niektore JavaScript schedulery wspieraja tez wiodace seconds. Ta strona pokazuje roznice zamiast zgadywania.

Dialects nie sa domyslnie przenosne

Unix crontab, node libraries, Kubernetes, GitHub Actions i Cloud Scheduler moga roznic sie seconds, aliases, macros, timezones i special characters. Traktuj to jako evidence parsera, potem zweryfikuj target runtime.

Timezone review jest czescia schedule review

Daily local-time schedule moze przesunac sie przy DST transitions. Porownaj local i UTC columns zanim obiecasz dokladny timing operacyjny.

Uzyj tych tras, gdy schedule review laczy sie z datami, release ranges albo environment configuration.

date-fns Format PlaygroundDay.js Date/Time PlaygroundSemver Range Playgrounddotenv Parser Playground

Cron Expression Playground | Playground Forge

Wyjasnij cron schedule zanim trafi na produkcje

Wyjasniaj cron expressions prywatnie w przeglądarce. Sprawdz nastepne uruchomienia, timezone i DST caveats, strict mode conflicts oraz bezpieczne diagnostyki parsera bez uruchamiania jobow.

01

Wyjasnij cron schedule zanim trafi na produkcje

Cron Expression Playground jest privacy-first powierzchnia review dla schedules, które wygladaja krotko, ale maja realny wpływ operacyjny. Obsluguje classic 5-field cron expressions, opcjonalne 6-field expressions z seconds oraz predefined shortcuts takie jak @daily. Route używa cron-parser lokalnie w przeglądarce, pokazuje next occurrences w local time i UTC, oraz nigdy nie uruchamia joba, nie wywoluje backendu i nie zapisuje expression.

02

Co wspiera MVP

MVP wspiera minute, hour, day-of-month, month, day-of-week i opcjonalne seconds fields, strict mode, mala timezone allowlist, current date control, occurrence count caps, field explanations, parser diagnostics, high-frequency warnings, predefined expression notes i DST caveats. To jest narzędzie do schedule review, a nie do deploymentu, monitoringu ani runtime discovery.

03

Dlaczego widoczne parsowanie cron zmniejsza ryzyko incydentu

Cron syntax kompresuje kilka decyzji do krotkiego stringa. Jedno przesuniete pole może uruchomic task o zlej godzinie, w zly weekday albo znacznie czesciej niz planowano. Zespoly często kopiuja schedule miedzy server crontab, Node scheduler, Kubernetes CronJob i cloud scheduler bez sprawdzenia, który dialect jest interpretowany. Widoczny parser zamienia ten review w konkretny dowod. Field breakdown wyjasnia, czy wartość jest wildcard, fixed value, step, range, list albo alias. To ma znaczenie, bo schedules takie jak */15 9-17 * * 1-5 komunikuja polityke tylko wtedy, gdy reviewer widzi jednoczesnie working window i weekday restriction. Next occurrence list zamienia interpretacje na realne timestamps, wiec reviewer może porownac local wall-clock time i UTC przed commitem. Strict mode istnieje dlatego, ze day-of-month i day-of-week combinations są czestym źródłem nieporozumien. Niektore runtimes interpretuja te pola inaczej, a niektore zespoly oczekuja relacji AND tam, gdzie parser może miec inna semantyke. Playground pokazuje ten konflikt jako kontrolowana diagnostyke zamiast zostawiac expression jako pozornie czysty. Timezone review jest równie ważny. Schedule stabilny w UTC może byc zaskakujacy dla local business hours, a local-time schedule może pominac albo powtorzyc wall-clock values przy DST transitions. Strona nie twierdzi, ze zastapi target scheduler. Daje wystarczajacy evidence, aby zadac właściwe deployment question zanim schedule zostanie uznany za zaufany.

04

Praktyczny workflow schedule review

Zacznij od najblizszego presetu, a potem podmien expression na schedule z review. Zostaw strict mode wlaczony, gdy chcesz parser-level safety dla ambiguous day fields, i wylacz go tylko wtedy, gdy swiadomie reviewujesz classic 5-field schedule. Ustaw current date na znane incident window, release date albo DST boundary, jezeli timing ma znaczenie. Najpierw przeczytaj field breakdown, potem occurrence list. Jezeli pierwsze pole pojawia się jako seconds, potwierdz, ze target runtime wspiera seconds field. Jezeli expression jest predefined shortcut, potwierdz, ze deployment target rozwija ten sam macro. Gdy pojawi się high-frequency diagnostic, sprawdź cost, retries, idempotency i rate limits zanim uznasz schedule za bezpieczny. Skopiowany snippet traktuj jako implementation evidence tylko dla projektow opartych o cron-parser. Dla Kubernetes, GitHub Actions, Cloud Scheduler, Quartz albo server crontab użyj outputu jako review note, a potem zweryfikuj target runtime documentation albo staging deployment. Ten podzial utrzymuje publiczne narzędzie jako użyteczne, ale nie udaje, ze każdy cron dialect jest wymienny. W review incydentowym najwieksza wartość daje porownanie co najmniej trzech kolejnych wystapien, pierwszego wystapienia po oknie release oraz reprezentacji UTC, która zobaczy zespol w logach. Dzięki temu pull request ma wspolny artefakt: expression, wykryty model pol, timezone, status strict mode i konkretna tabele next-run. Gdy schedule trafia pozniej do Terraform, Kubernetes, GitHub Actions, Cloud Scheduler albo process managera, wynik playgroundu powinien isc razem z review jako evidence, a nie jako zamiennik dokumentacji docelowego schedulera.