Cron Expression Generator

A standard cron expression has five space-separated fields. Each field accepts a value, and together they define when a job runs:

* * * * *
| | | | |
| | | | +-- day of week  (0-7, Sun=0 or 7)
| | | +---- month        (1-12 or JAN-DEC)
| | +------ day of month (1-31)
| +-------- hour         (0-23)
+---------- minute       (0-59)

An optional sixth field at the front adds seconds - this is supported by schedulers like node-cron and Quartz, but not by standard system cron.

The characters ?, L, W, and # are Quartz-only (used by Java schedulers) and are not valid in real Unix cron - avoid them unless your scheduler is Quartz.

Most cron implementations accept these convenient nicknames:

This trips up almost everyone. When both the day-of-month and day-of-week fields are restricted (neither is *), cron runs the job when either one matches - an OR, not an AND.

So 0 0 13 * 5 runs at midnight on the 13th of any month and every Friday - not only on Friday the 13th. To target a specific weekday in a specific month, keep day-of-month as *.

Each user has their own crontab (stored under /var/spool/cron). System-wide jobs live in /etc/crontab and /etc/cron.d/ - those add an extra user field between the schedule and the command. Drop-in scripts also go in /etc/cron.daily, /etc/cron.hourly, and so on.

• Minimal PATH. Cron does not load your shell profile, so node or python may not be found. Use absolute paths (/usr/bin/node) or set PATH at the top of the crontab.
• No output, no clue. Redirect output to a log: ... >> /var/log/job.log 2>&1. Otherwise failures vanish (or get mailed).
• Unescaped %. A literal percent sign must be escaped as \% in crontab - unescaped, it is treated as a newline.
• MAILTO. Set MAILTO=you@example.com to receive job output by email, or MAILTO="" to silence it.
• Timezone. Cron uses the server's timezone. Set CRON_TZ=UTC at the top of the crontab to pin it, and remember DST can shift local schedules.

To see whether a job fired, check the cron log - grep CRON /var/log/syslog on Debian/Ubuntu, or journalctl -u cronwith systemd. Then run the exact command by hand to confirm it works outside cron's minimal environment.

For anything beyond simple scheduling - dependencies, retries, accurate logging, missed-run catch-up - modern Linux systems often prefer systemd timers, which integrate with the journal and service management. Cron remains the simplest choice for straightforward, recurring tasks.