Cron Expression Generator & Explainer
Build, decode and validate cron schedules in real time, with the next run times shown in the zone your server actually uses.
Build, decode and validate cron schedules in real time, with the next run times shown in the zone your server actually uses.
Writing cron jobs manually often leads to silent server failures. Layerbit's Synthesizer acts as an interactive compiler, translating dense server logic into plain English instantly to prevent production downtime.
Automate your GitHub Actions, Jenkins, or GitLab CI pipelines by generating strict POSIX-compliant syntax. Schedule nightly builds, dependency updates, or automated testing environments with absolute precision.
Configure perfectly timed MySQL or PostgreSQL database dumps, log rotations, and cache invalidation scripts without guessing the minute/hour array mapping.
Generate valid syntax for AWS EventBridge (CloudWatch Events), Azure Functions, or Google Cloud Scheduler to trigger serverless functions exactly when your application traffic demands it.
A cron expression is a string comprising five or six fields separated by white space that represents a set of times, normally as a schedule to execute a specific routine or script. It is the standard time-based job scheduler in Unix-like computer operating systems.
The most common reason for unexpected scheduling is timezone discrepancies. By default, most cloud servers and CI/CD pipelines (like GitHub Actions) operate strictly on Coordinated Universal Time (UTC). If you schedule a job for 9:00 AM local time, you must calculate and apply the correct UTC offset in your expression.
Standard POSIX cron utilizes 5 fields (Minute, Hour, Day of Month, Month, Day of Week). Some advanced schedulers (like Quartz) utilize a 6th or 7th field for Seconds and Years. Layerbit currently generates universal 5-field syntax, which guarantees the highest compatibility across all major operating systems and cloud providers.
An incorrect cron expression is still a valid cron expression. There is no syntax error to catch and no test that fails — just a job quietly running at the wrong times, sometimes for months, until someone notices a report covering the wrong window. The most misread rule is this one:
*), the job runs when either matches. It is an OR, not an AND.0 0 13 * 5 — intended as "midnight on Friday the 13th" — actually fires on the 13th of every month and every Friday. Roughly 64 times a year instead of one or two.POSIX and Vixie cron both specify this, so it is not a bug you can work around by switching implementations. There is no cron syntax for a true AND: "the first Monday of the month" cannot be expressed in five fields. The conventional approach is to schedule the superset and guard inside the job. Our cron guide works through this and the other traps in full.
*/7 means "every 7th value in the range", not "every seven minutes". Since 60 is not divisible by 7 it fires at 0, 7, 14 … 56, then resets — leaving one four-minute gap per hour. Only divisors of 60 give a uniform cadence.
Classic cron uses local time. When clocks spring forward a job in the skipped hour usually does not run; when they fall back it may run twice. Run the host in UTC, or set CRON_TZ=UTC, and convert inside the application.
L, W, # and ? are Quartz extensions, and much "cron documentation" online is actually Quartz documentation. They fail in a standard crontab — often silently. Quartz also uses six or seven fields to cron's five.
Because a wrong expression looks reasonable, the only reliable verification is to read the schedule back as a sentence and look at the actual dates it will fire on. This tool does both: it translates the expression into plain English and computes the next five fire times in UTC. If the sentence does not match your intent, or the dates include days that surprise you, the expression is wrong regardless of how sensible it looks.
The times are shown in UTC deliberately rather than in your local timezone. Most managed schedulers — GitHub Actions, AWS EventBridge, Google Cloud Scheduler — evaluate cron in UTC, and presenting local times would hide exactly the offset that causes the mistakes.
When a schedule is correct but nothing happens, it is usually one of these rather than the cron syntax:
/usr/bin:/bin. Your shell's PATH is not inherited, so use absolute paths for every binary.%. In a crontab this is special — it truncates the command and sends the remainder to standard input. Escape it as \%.>> /var/log/job.log 2>&1 — a cron job with no log is one you cannot debug and cannot prove ran.flock -n /tmp/job.lock /path/to/job.sh, with -n so you skip rather than queue.61 * * * * is refused with the offending field and its valid range, instead of being rendered as "at 61 minutes past the hour". Month and weekday names are validated too.