Kreator wyrażeń Cron

Build and decode any cron expression

This cron expression generator works two ways at once. Build a schedule with the visual fields and the expression writes itself; or type an expression — or paste one from a config — and the tool decodes it into plain English, validates every field, and previews the next run times. It's a cron builder, a crontab generator and a cron expression validator in one, and everything happens locally in your browser.

Scheduling a Linux crontab entry, a CI pipeline, a Spring @Scheduled task, a GitHub Actions workflow schedule, or an AWS EventBridge rule — you can get the syntax right the first time instead of guessing and re-deploying.

The five cron fields — plus seconds

A standard Unix cron expression has five fields: minute (0–59), hour (0–23), day-of-month (1–31), month (1–12 or JAN–DEC) and day-of-week (0–6 or SUN–SAT). Quartz, Spring and Azure add a seconds field at the front, and Quartz and AWS add an optional year at the end. The builder shows exactly the columns your chosen flavour uses, so you never miscount fields.

Day-of-week is the field people misread most. Unix and Spring number it 0–6 with 0 = Sunday (7 also works as Sunday), while Quartz and AWS number it 1–7 with 1 = Sunday. That's why the same number can mean different days in different systems — the descriptor always spells out the day name.

Operators: * , - and /

Four operators cover almost every schedule. The asterisk * matches every value. A comma builds a list (1,15 = the 1st and 15th). A hyphen builds a range (MON-FRI = weekdays). A slash adds a step (*/10 = every 10th value; 0/30 = starting at 0, every 30). Combine them — */15 9-17 * * 1-5 means "every 15 minutes from 9am to 5pm on weekdays." Quartz and AWS add advanced tokens like L (last), W (nearest weekday) and # (nth weekday), which the tool explains in the description.

Multiple cron flavours: Unix, Quartz, Spring, AWS & Azure

Most online tools only handle 5-field Unix cron. This one switches between Unix/crontab, Quartz (Java, 6–7 fields), Spring (@Scheduled, 6 fields), AWS EventBridge (6 fields with year and a required ?) and Azure NCRONTAB (6 fields). Choosing a flavour changes the field set, the day-of-week numbering and the syntax rules — including Quartz's and AWS's requirement that one of day-of-month or day-of-week be a ? — so you copy an expression that actually works in your target system.

How this compares to crontab.guru and other cron tools

Crontab.guru is the best-known cron decoder, but it's read-only — paste an expression in and it explains it, but there's no visual builder and no support for Quartz, Spring, AWS EventBridge or Azure NCRONTAB. Tools like freeformatter.com/cron-expression.html handle Quartz but lack a visual builder and next-run preview. Cronhub and Cronitor are full cron monitoring platforms that require a free account before you can even validate an expression.

This tool covers all five flavours with a visual builder, a plain-English decoder, field-level validation, and a next-run timeline — all in one page, with no account and no upload. The expression stays in your browser, so it's safe for internal job names or sensitive schedule configs you'd rather not send to a third-party server.

Preview the next run times and validate as you go

The next run times panel answers the real question — "when will this actually fire?" — by computing the upcoming executions in your local timezone, so tricky day-of-month and day-of-week combinations hold no surprises. If a field is out of range or has the wrong number of values, the validator points to the exact problem instead of failing silently.

Start from the nickname buttons (@hourly, @daily, @weekly, @monthly, @yearly) or the common-schedule gallery — every 5, 15 or 30 minutes, weekdays at 9am, the 1st of the month — then fine-tune any field. Copy the finished expression, or copy a shareable link that reopens the tool with your schedule and flavour preloaded.

Private, instant and free — works on any device

There's nothing to install and no account to create. Parsing, description, validation and the next-run calculation all run in JavaScript on your device — your expressions are never uploaded, logged or shared. The tool works on iPhone, Android, Mac, Windows and Linux — open it in any browser and it's fully functional. Bookmark this cron expression generator as your go-to for reading, writing and double-checking cron schedules across every flavour.

The history of cron: from Bell Labs to the cloud

The cron daemon was written by Ken Thompson at Bell Labs and shipped with Unix Version 7 in 1979. The name comes from Chronos, the Greek personification of time — a fitting tribute for a daemon whose entire purpose is to act at precise moments. Thompson's original implementation was a single system daemon: it woke up once per minute, scanned a hard-coded list of scheduled commands, and forked a child process for any job whose time had come. The concept was simple enough to fit in a handful of C functions, yet robust enough that the core model has barely changed in 45 years.

The crond daemon at the OS level works exactly the same way today. On startup it reads every user's personal crontab file (edited with crontab -e), the per-package drop-in files in /etc/cron.d/, and the system-level /etc/crontab — which adds an extra user column so the system knows which account to run each job as. Once per minute crond compares the current wall-clock time to each expression; if all five fields match, it forks a child, sets the environment variables, and executes the command. The simplicity is intentional: cron has no retry logic, no dependency resolution, and no visibility into whether the previous run is still in progress.

Modern Linux distributions are gradually replacing cron with systemd timers, which integrate with the journal for logging, support monotonic (elapsed-time) schedules, and can declare dependencies between units. But cron expressions live on everywhere else — in cloud schedulers, CI systems, container orchestrators, and application frameworks — because the five-field syntax is so well understood that abandoning it would cost more than it saves.

5-field, 6-field and 7-field cron: why the same string behaves differently on different platforms

Standard Unix cron has exactly five fields (minute, hour, day-of-month, month, day-of-week). Many modern platforms prepend a seconds field at position zero, creating a six-field expression. Jenkins, Spring @Scheduled, Azure Functions NCRONTAB and many cloud schedulers all use this six-field form. Quartz Scheduler (the dominant Java job-scheduling library) uses six fields and optionally a seventh year field at the end. AWS EventBridge (formerly CloudWatch Events) also uses six fields but its sixth field is year, not seconds — making it the most different format of all.

This creates real ambiguity. The expression 0 * * * * means "at minute 0 of every hour" (hourly) in a five-field Unix crontab. Paste that same string into a system whose parser expects six fields and it is silently reinterpreted: 0 becomes the seconds field and * becomes the minutes field, so the job fires every second of every minute of hour 0 — 3,600 times a night instead of once an hour. Always confirm how many fields your target system expects before copying an expression between platforms. The flavour selector in this tool adjusts the field count automatically and keeps the columns labeled so you never miscount.

Quartz also introduces advanced tokens unavailable in Unix cron: L means "last" (the last day of the month, or the last Friday), W selects the nearest weekday to a given date (15W fires on the 15th if it's a weekday, otherwise the closest Monday or Friday), and # means "the nth occurrence" (2#1 is the first Monday of the month). AWS EventBridge supports L and ? but not W or #. These tokens are powerful but platform-specific — the tool flags them as unsupported if you switch to a flavour that doesn't recognise them.

Common cron patterns and the business logic behind them

Most production cron jobs cluster around a handful of canonical patterns, each chosen to match a real business rhythm. 0 2 * * * — daily at 2 am — is the classic database backup slot: traffic is at its nightly low, replica lag is minimal, and the window is wide enough for a long-running dump to finish before the morning spike. 0 9 * * 1-5 targets weekday mornings at 9 am for jobs that only make sense during business hours — sending a daily digest email, warming a cache before staff log in, or triggering a report that a manager will read at their desk. 0 0 1 * * fires at midnight on the 1st of each month for billing runs, monthly aggregate reports, or SLA resets. 0 0 * * 0 runs every Sunday at midnight for heavier weekly cleanups — purging soft-deleted records, reindexing a search engine, or rotating log archives.

Shorter intervals have different uses. */15 * * * * (every 15 minutes) is the standard health-check or metrics-push cadence: frequent enough to catch an outage quickly, infrequent enough not to hammer a downstream API. 0 8 1,15 * * — the 1st and 15th at 8 am — mirrors a bi-monthly payroll cycle. The Quartz expression 30 5 L * ? fires at 05:30 on the last day of every month, useful for end-of-month closing jobs that must run regardless of whether the month has 28, 29, 30 or 31 days.

One edge case trips up many engineers: day-of-month values higher than a given month contains are silently skipped. Scheduling a job on the 31st with 0 0 31 * * means it never runs in February, April, June, September or November. If you need genuine end-of-month coverage, use Quartz's L token or fall back to running on the 28th and applying application-level logic to decide whether today is actually the last day.

Cron in cloud and serverless environments

AWS EventBridge Scheduler (the successor to CloudWatch Events) offers two expression types: a human-readable rate() expression such as rate(1 hour), and a six-field cron expression that includes a year field. Since 2022 EventBridge natively supports IANA timezone names, which means you can schedule a job for 09:00 America/New_York instead of calculating the UTC offset yourself and re-editing twice a year around daylight saving time. GCP Cloud Scheduler also supports IANA timezone names and uses a Quartz-style six-field format. Azure Logic Apps exposes scheduling through a recurrence trigger in its low-code designer, but under the hood it accepts NCRONTAB (six-field, seconds-first) strings when you switch to code view.

GitHub Actions on: schedule uses a standard five-field UTC cron expression with a platform minimum interval of five minutes — GitHub explicitly blocks expressions that would fire more often. In practice, heavily loaded runners mean the actual delay between the scheduled time and job start can be 15 to 30 minutes during peak periods, so GitHub Actions schedules are unsuitable for anything time-sensitive. Kubernetes CronJob accepts five-field expressions and the @daily, @weekly, @hourly and @monthly shorthands, and uses the timezone of the cluster's kube-controller-manager process — a common source of surprise when a cluster runs in UTC but the team expected local time. As of Kubernetes 1.27 the spec.timeZone field reached stable, allowing per-CronJob IANA timezone control. Heroku Scheduler is the most constrained of all: it offers only a GUI with three fixed intervals (every 10 minutes, hourly, or daily) and does not accept cron syntax at all.

Cron vs message queues vs event-driven scheduling: when time-based scheduling is the wrong tool

Cron is time-triggered: it fires at a fixed clock time, regardless of whether the system is under load, whether the previous run finished, or whether there is actually any work to do. That simplicity is a virtue for truly periodic tasks — rotating logs, expiring tokens, sending a scheduled newsletter — but it becomes a liability when the volume of work is variable. A nightly batch job that processes "all records created today" is only right-sized by coincidence; on a quiet night it finishes in seconds, on a busy night it runs for hours and potentially overlaps with the next scheduled run.

The canonical alternative is a message queue: records are enqueued when they are created, and workers pull from the queue continuously. The system self-regulates under load, there is no wasted empty run on quiet nights, and failures are retried automatically. In Python, Celery Beat bridges both worlds — it uses cron-like schedules to periodically enqueue tasks that workers then process asynchronously. Sidekiq Scheduler does the same in Ruby. In Node.js, Bull and BullMQ support repeatable jobs backed by Redis, with cron string syntax and automatic leader-election to prevent duplicate firings across multiple instances.

The multi-instance problem is cron's deepest scaling flaw: if you deploy three instances of an application and each one has the same cron job wired up, the job fires three times simultaneously. Solutions range from a distributed lock (acquire a Redis or database lock at the start of each run, skip if already held) to a dedicated scheduler process that owns all cron logic and dispatches work to the fleet. Serverless platforms such as Inngest, Trigger.dev and Quirrel solve this by hosting the scheduler externally and delivering a single HTTP call to your function at the scheduled time — your code scales horizontally without any locking logic. The right mental model: use cron when the schedule itself is the source of truth; use a queue when the arrival of data is the source of truth.