Crontab Command Cheat Sheet
Schedule commands correctly, understand cron syntax, and troubleshoot jobs that do not run.
Before you start
Cron Time Format
A standard crontab line uses five time fields followed by the command:
* * * * * /path/to/commandThe five fields are minute, hour, day of month, month, and day of week. If these are wrong, the job will not run when you expect.
Basic Crontab Commands
These are the most important commands for day-to-day cron management.
crontab -e
crontab -l
crontab -r
crontab -e edits the current user's cron jobs, crontab -l lists them, and crontab -r removes them. Be especially careful with removal.
Useful Schedule Examples
These patterns cover many real server automation tasks.
*/5 * * * * /path/to/script.sh
0 * * * * /path/to/script.sh
0 0 * * * /path/to/script.sh
0 3 * * 0 /path/to/script.sh
30 2 1 * * /path/to/script.shThese mean every 5 minutes, every hour, every day at midnight, every Sunday at 3:00, and the first day of each month at 2:30.
Always Use Absolute Paths
One of the most common cron mistakes is relying on relative paths or on shell environment assumptions.
*/10 * * * * /usr/bin/php /home/example/public_html/cron/job.phpCron may not know where your command is unless you specify the full path. This is a major reason jobs fail even though the command works manually.
Log Output for Troubleshooting
If a cron job does not behave as expected, capture its output. Silent failure is common when jobs are not logged.
*/10 * * * * /usr/bin/php /home/example/public_html/cron/job.php >> /home/example/logs/cron.log 2>&1Standard output and errors are written into a log file. This makes it much easier to confirm whether the job ran and what failed.
Real example
A backup script works correctly when run manually, but nothing happens when it is placed in crontab. After adding output redirection and replacing the command with absolute paths, the issue becomes clear: the script depended on an environment variable that cron did not provide. Once the path and environment assumptions were fixed, the job ran normally.
This is a classic cron troubleshooting pattern. The job itself is not broken. The execution environment is different.
Possible causes
- Wrong cron time expression
- Missing absolute path to command or script
- File permission problems
- Environment variables missing under cron
- Script depends on a different shell or working directory
- No log output, so failures remain invisible
Common mistakes
- Using relative paths in cron commands
- Testing manually and assuming cron will behave identically
- Forgetting to capture output to a log file
- Writing a valid command but the wrong schedule
- Editing crontab without confirming the user context
Environment tips
- Use
crontab -lafter editing to verify the final saved job list. - Always use full paths for commands, scripts, and output files.
- Log stdout and stderr with
> logfile 2>&1when testing or when the job is operationally important. - When a job fails only in cron, compare the cron environment against your interactive shell assumptions.
About this guide
This is a complete crontab reference for real Linux server operations. It covers schedule syntax, useful examples, output logging, common mistakes, and practical troubleshooting when a cron job does not run as expected.
How to follow this guide
- Use crontab -e to edit scheduled jobs for the current user.
- Understand the five cron time fields before writing schedules.
- Always use absolute paths in cron commands.
- Redirect output to a log file when testing or troubleshooting.
- Verify execution environment because cron does not behave like an interactive shell.
Why use this method?
Cron is one of the most important automation tools on Linux servers. It is used for backups, cleanup jobs, scripts, reports, maintenance tasks, and timed application workflows. A strong crontab reference saves time and prevents silent scheduling failures.
Frequently Asked Questions
What is crontab?
crontab is the user-level interface for managing cron jobs, which are scheduled commands or scripts that run automatically at specified times.
Why does my cron job work manually but fail in crontab?
Cron runs with a limited environment. Missing PATH values, relative paths, permissions, shell differences, and missing output logging are common reasons.
What do the five fields in crontab mean?
They represent minute, hour, day of month, month, and day of week, followed by the command to run.
Should I always log cron output?
For real server work, yes. Logging output is one of the fastest ways to understand whether the job ran and what happened.