cron.md

Cron jobs are the Unix way of telling your computer: “At this time, do that thing, relentlessly, forever.” Think of it as a tiny, tireless scheduler living in your system’s basement, checking its watch every minute ⏱️.

Here’s the clean, practical path.

First, open your crontab (cron table) for editing:

crontab -e

The first time, it may ask which editor you prefer (nano is the least painful if you’re unsure).

Each cron job is one line with this structure:

* * * * * command_to_run

Those five stars are time fields, in this exact order:

minute hour day_of_month month day_of_week

Examples make this click instantly.

Run a script every day at 3:30 AM:

30 3 * * * /path/to/script.sh

Run a Python script every 5 minutes:

*/5 * * * * /usr/bin/python3 /home/user/task.py

Run something every Monday at 9 AM:

0 9 * * 1 /path/to/command

A few sharp edges cron will not warn you about:

• Always use full paths. Cron does not know your shell shortcuts. Bad:

python script.py

Good:

/usr/bin/python3 /home/user/script.py

• Scripts must be executable.

chmod +x script.sh

• Cron has a tiny environment. If your script relies on environment variables, set them inside the script or explicitly in the crontab.

To see what cron jobs are currently set:

crontab -l

To remove all cron jobs (dangerous but sometimes necessary):

crontab -r

If something isn’t running, check logs:

grep CRON /var/log/syslog

(or /var/log/cron on some systems).

One philosophical note from the machine room: cron is brutally literal. It will do exactly what you told it to do, not what you meant. When debugging, add logging:

* * * * * /path/to/script.sh >> /tmp/cron.log 2>&1

That log file becomes your oracle.

Cron is simple, old, and extremely powerful—the Unix equivalent of a pocket watch that refuses to die. Once you trust it, you stop thinking about it, which is exactly its job.