Crontab Expression Editor

Cron is the scheduler that runs tasks automatically on Unix and Linux systems, and it is driven by a compact five-field expression that many people find hard to read at a glance. This tool translates that expression into a sentence and shows the next times it will run, so you can verify a schedule before you trust it. The syntax is terse but completely learnable once you see how the fields and operators fit together.

The five fields

A cron line has five space-separated fields, always in the same order: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-7, where both 0 and 7 mean Sunday). Reading left to right, the expression 30 8 * * * means minute 30, hour 8, every day of the month, every month, every day of the week - in other words, 08:30 every day. Getting the order right is half the battle, because a value in the wrong column silently schedules something completely different.

The operators

Four operators unlock almost every schedule you will ever need. An asterisk * means "every valid value" for that field. A step like */n means "every n units", so */15 in the minute field fires at minutes 0, 15, 30, and 45. A range a-b covers a contiguous span, so 1-5 in the day-of-week field means Monday through Friday. A comma list a,b picks specific values, so 0,30 in the minute field runs on the hour and the half hour. Combine them and you get expressions like 0 9 * * 1-5 (09:00 on weekdays), */15 * * * * (every fifteen minutes), or 0 3 * * * (03:00 every day, a common time for nightly maintenance).

The day-of-month versus day-of-week quirk

One rule surprises almost everyone. When both the day-of-month field and the day-of-week field are restricted (neither is *), cron treats them as an OR, not an AND. The expression 0 0 13 * 5 does not mean "midnight on Friday the 13th" - it means "midnight on the 13th of the month OR any Friday", so it fires far more often than you expect. The job runs if either condition matches. This tool's plain-English output and next-run list make the quirk obvious, which is exactly the kind of mistake that is painful to discover in production.

Why cron matters for hackers and defenders

Cron is a classic Linux privilege-escalation surface. If a job defined in root's crontab runs a script that a lower-privileged user can write to, that user can overwrite the script and have their own code executed as root the next time it fires. A subtler version is PATH hijacking: if a root cron job calls a program by its bare name (for example backup instead of /usr/local/bin/backup) and the crontab sets a PATH that includes a directory the attacker controls, they can drop a malicious backup earlier in the search path and it will run with root privileges. Defenders audit this by reviewing every entry under /etc/crontab, /etc/cron.d/, and per-user crontabs, checking that scripts and their directories are not writable by non-root users, and confirming that jobs call binaries by absolute path. As a worked example, */15 9-17 * * 1-5 reads as "every 15 minutes, between 09:00 and 17:00, Monday through Friday" - a business-hours polling job that a defender might expect, and an attacker might try to co-opt.