Cron Expression Builder
Build and explain cron expressions for Linux, Node.js, GitHub Actions, and AWS. See exactly when your schedule will run. Browser only.
Cron Expression Builder
Runs entirely in your browser — no server calls, no tracking.
Enter fields and click Build expression.
🔒 Your data never leaves this tab. This tool has no backend.
About the Cron Expression Builder
A cron expression is a 5-field string (minute hour day-of-month month day-of-week) that defines a recurring schedule for automated tasks. It is used in Linux crontab, GitHub Actions, AWS EventBridge, Kubernetes CronJobs, Node.js schedulers, and dozens of other systems. This tool generates the expression from human-readable fields and shows the ready-to-copy syntax for the most common platforms.
Field syntax reference
* — every unit. */n — every nth unit (e.g. */15 in the minute field = every 15 minutes). n-m — range (e.g. 1-5 in day-of-week = Monday to Friday). n,m — list (e.g. 1,3,5 = Mon, Wed, Fri). You can combine: 0,30 9-17 * * 1-5 = at :00 and :30 past each hour from 9am to 5pm, weekdays.
Timezone warning
Cron schedules run in the system timezone of the machine or the configured timezone of the service. A cron job set to 0 9 * * * runs at 9am in whatever timezone the server is configured to. AWS EventBridge rules always run in UTC. GitHub Actions always run in UTC. Always specify whether your intended time is UTC or local, and document it in your code.
GitHub Actions uses a 6-field cron with second-level granularity in some contexts, but the standard Actions schedule trigger uses the standard 5-field POSIX format (UTC). GitHub does not guarantee exact execution time — jobs may be delayed by minutes during periods of high runner demand.
Reading a cron expression, and the traps in scheduling
A cron expression is five fields separated by spaces, each describing when a job should run.
| Field | Range | Example |
|---|---|---|
| Minute | 0–59 | 0 |
| Hour | 0–23 | 3 |
| Day of month | 1–31 | * |
| Month | 1–12 | * |
| Day of week | 0–6 (Sunday = 0) | 1 |
So 0 3 * * 1 means 03:00 every Monday. */15 * * * * means every fifteen minutes. 0 0 1 * * means midnight on the first of each month.
Day-of-month and day-of-week together
The genuinely counter-intuitive rule: when both day fields are restricted, cron runs the job if either matches, not both. 0 0 13 * 5 runs on the 13th of every month and on every Friday — not only on Friday the 13th. If you need an AND, restrict one field and test the other inside your script.
Timezones and daylight saving
Cron uses the server's local timezone unless told otherwise, which makes the clock change genuinely dangerous. When clocks go forward, a job scheduled inside the skipped hour never runs. When they go back, a job in the repeated hour may run twice. Schedule anything critical in UTC, or outside 01:00–03:00 local time.
Practical scheduling
Avoid exactly on the hour — every system in the world fires then, so shared infrastructure spikes. 7 3 * * * is a better choice than 0 3 * * *. And cron will happily start a second run while the first is still going, so use a lock file if overlapping runs would cause problems.
Frequently asked questions
It runs at 03:00 every Monday. The five fields are minute, hour, day of month, month and day of week — so minute 0, hour 3, any day of month, any month, day of week 1 which is Monday. Sunday is 0 in most cron implementations.
Most likely the day-of-month and day-of-week rule. When both fields are restricted, cron runs the job if either matches, not both. So 0 0 13 * 5 runs on the 13th of every month and on every Friday, not just on Friday the 13th.
The server's local timezone unless configured otherwise, which makes daylight saving a real hazard. A job scheduled inside the skipped hour when clocks go forward never runs, and one inside the repeated hour when they go back may run twice. Schedule critical jobs in UTC or outside 01:00 to 03:00.
Use */15 * * * * — the step value in the minute field fires at 0, 15, 30 and 45 past every hour. The same syntax works elsewhere: */2 in the hour field runs every two hours.
Cron starts the second run anyway — it does not check. If overlapping runs would cause double-processing or lock contention, use a lock file or a tool like flock so a new run exits immediately when one is already active.
@daily (0 0 * * *), @weekly (0 0 * * 0), @monthly (0 0 1 * *), and @hourly (0 * * * *) are supported in most Linux crontab implementations. They are not supported in GitHub Actions or AWS EventBridge, which require the full 5-field expression.*/5 * * * *. The */n syntax means "every nth value". */5 in the minute field triggers at :00, :05, :10, :15... up to :55. Similarly, */2 * * * * runs every 2 minutes, 0 */4 * * * runs at midnight, 4am, 8am, noon, 4pm, 8pm each day.H (hash) syntax (Jenkins uses this) to deterministically stagger jobs. AWS EventBridge has a jitter feature for this purpose.Need automated workflows or background jobs built?
ruxox builds scheduled jobs, automation pipelines, and background processing systems. Free estimate in 48 hours.