Type an expression and it’s translated back into English, along with the next few times it fires.

Next runs, in your timezone

As a systemd timer

cron will tell you a job failed, since it logs to syslog and mails you the output, if you’re monitoring those systems. It won’t do anything about that failure. No retries, no catch-up for runs missed while the machine was off, no failure handlerhas no built-in logging, error handling, or retry logic.

If you’re on a system with systemd, my systemd timer generator builds both the .timer and .service files. In a containerized application, Kubernetes has a CronJob workload to consider.

Field syntax

Syntax	Means	Example
*	every value	* * * * * — every minute
,	a list	0,30 * * * * — on the hour and the half hour
-	a range	0 9-17 * * * — every hour from 09:00 to 17:00
/	a step	*/10 * * * * — every 10 minutes
names	months and weekdays	0 4 * * sun or 0 0 1 jan *

Day of week runs 0–7 with both 0 and 7 meaning Sunday. When both day of month and day of week are restricted, cron fires when either one matches — so 0 0 13 * fri runs on Friday and on the 13th, not only on Friday the 13th.

Shorthands

Shorthand	Equivalent
@yearly, @annually	0 0 1 1 *
@monthly	0 0 1 * *
@weekly	0 0 * * 0
@daily, @midnight	0 0 * * *
@hourly	0 * * * *
@reboot	once at startup

Checking a real crontab

crontab -l              # what is scheduled for you
sudo crontab -l -u root # ... and for someone else
ls -l /etc/cron.d/      # packages drop their own schedules here

Cron mails output to the crontab’s owner, so a job that prints anything on success will fill up a mailbox nobody reads. Redirect it, or keep quiet on success:

0 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

Cron also runs with a nearly empty environment — no PATH beyond /usr/bin:/bin, no shell profile, no TZ. Use absolute paths for everything, and set what you need at the top of the crontab:

PATH=/usr/local/bin:/usr/bin:/bin
MAILTO=me@example.com