Cookie consent and privacy
Optional measurement and Google services run only after your consent. The consent panel (CMP) stores your choice; rejecting does not block the playgrounds.
Schedule explainer

Explain cron schedules before they wake production

Paste a 5-field or 6-field cron expression, choose a timezone and see the next occurrences, field breakdown and controlled parser diagnostics. The evaluator runs locally and never schedules a job.

  • No backend scheduler
  • Timezone and DST caveats
  • Strict mode diagnostics

A private review surface for schedules

Cron syntax is compact enough to hide mistakes. This playground expands minutes, hours, day-of-month, month, day-of-week and optional seconds into a readable review surface before a schedule reaches CI, Kubernetes, Cloud Scheduler or a server crontab.

The page does not run jobs, call a backend, fetch project config, store schedules, write URL state or send custom analytics payloads with your expression, timezone, date or occurrence list.

Cron workbench

Start from a preset, edit the expression and compare field semantics with upcoming local and UTC run times.

Clean

Every 15 minutes during a weekday working window in Europe/Warsaw.

Schedule input

Evaluation result

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

Diagnostics

DST caveat

Local timezone schedules can skip or repeat wall-clock times during daylight saving transitions.

Europe/Warsaw

Field breakdown

Second0

Fixed: runs only when the field equals this value.

Minute*/15

Step: repeats through the field at the configured interval.

step
Hour9-17

Range: accepts values between the lower and upper bound.

range
Day of month*

Wildcard: accepts every value in this field.

wildcard
Month*

Wildcard: accepts every value in this field.

wildcard
Day of week1-5

Range: accepts values between the lower and upper bound.

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

Five fields and six fields mean different things

Classic cron uses minute, hour, day-of-month, month and day-of-week. Some JavaScript schedulers also support a leading seconds field. This page makes that difference visible instead of guessing.

Dialects are not portable by default

Unix crontab, node libraries, Kubernetes, GitHub Actions and Cloud Scheduler can differ on seconds, aliases, macros, timezones and special characters. Treat this as parser evidence, then verify the target runtime.

Timezone review is part of schedule review

A daily local-time schedule can shift around DST transitions. Compare local and UTC columns before promising exact operational timing.

Use these routes when schedule review connects to dates, release ranges or environment configuration.

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

Cron Expression Playground | Playground Forge

Explain a cron schedule before it reaches production

Explain cron expressions privately in the browser. Preview next run times, timezone and DST caveats, strict mode conflicts and safe parser diagnostics without scheduling jobs.

01

Explain a cron schedule before it reaches production

Cron Expression Playground is a privacy-first review surface for schedules that look small but carry real operational impact. It accepts classic 5-field cron expressions, optional 6-field expressions with seconds and predefined shortcuts such as @daily. The route uses cron-parser locally in the browser, shows the next occurrences in local time and UTC, and never schedules a job, calls a backend or stores the expression.

02

What the MVP supports

The MVP supports minute, hour, day-of-month, month, day-of-week and optional seconds fields, strict mode, a small timezone allowlist, current date control, occurrence count caps, field explanations, parser diagnostics, high-frequency warnings, predefined expression notes and DST caveats. It is built for schedule review, not for deployment, monitoring or runtime discovery.

03

Why visible cron parsing reduces incident risk

Cron syntax compresses several decisions into a short string. A single misplaced field can run a task at the wrong hour, on the wrong weekday or far more often than intended. Teams often copy a schedule between a server crontab, a Node scheduler, a Kubernetes CronJob and a cloud scheduler without checking which dialect is being interpreted. A visible parser makes that review concrete. The field breakdown explains whether a value is a wildcard, fixed value, step, range, list or alias. That matters because schedules like */15 9-17 * * 1-5 communicate policy only if the reviewer can see both the working window and the weekday restriction. The next occurrence list then turns that interpretation into actual timestamps, so a reviewer can compare local wall-clock time and UTC before committing a schedule. Strict mode exists because day-of-month and day-of-week combinations are a common source of misunderstanding. Some runtimes interpret those fields differently, and some teams expect an AND relationship where the parser may apply different semantics. The playground surfaces that conflict as a controlled diagnostic instead of letting the expression look clean. Timezone review is just as important. A schedule that looks stable in UTC can be surprising for local business hours, while a local-time schedule can skip or repeat wall-clock values around DST transitions. The page does not claim to replace the target scheduler. It gives enough evidence to ask the right deployment question before the schedule is trusted.

04

A practical schedule review workflow

Start with the closest preset, then replace the expression with the schedule under review. Keep strict mode enabled when you want parser-level safety for ambiguous day fields, and turn it off only when you intentionally review a classic 5-field schedule. Set the current date to a known incident window, release date or DST boundary when timing matters. Read the field breakdown before the occurrence list. If the first field appears as seconds, confirm that the target runtime supports a seconds field. If the expression is a predefined shortcut, confirm that the deployment target expands the same macro. If high-frequency diagnostics appear, review cost, retries, idempotency and rate limits before treating the schedule as safe. Use the copied snippet as implementation evidence for cron-parser based projects only. For Kubernetes, GitHub Actions, Cloud Scheduler, Quartz or a server crontab, use the output as a review note and then verify the target runtime documentation or a staging deployment. That distinction keeps the public tool useful without pretending that every cron dialect is interchangeable. For incident review, the most useful workflow is to compare at least three future occurrences, the first occurrence after a release window, and the UTC representation that downstream logs will use. That gives reviewers a shared artifact for change requests: the expression, detected field model, timezone, strict-mode status, and exact next-run table. When a schedule is copied into Terraform, Kubernetes, GitHub Actions, Cloud Scheduler, or a process manager, the playground output should travel with the pull request as evidence, not as a replacement for the target scheduler documentation.