A cron job failing to execute on schedule typically stems from environment mismatches, incorrect permissions, or service interruptions. By verifying the crontab syntax, ensuring absolute paths for commands like
curl, and checking system logs, you can isolate the root cause. This guide provides a systematic approach to diagnosing why your scheduled tasks are not running as expected.
Verifying Crontab Syntax and Environment
The most common reason for a cron job appearing to fail is an error in the time specification or the command itself. The five-field time format (minute, hour, day of month, month, day of week) must be precise. A single typo here will prevent execution entirely. Additionally, cron runs in a minimal environment that lacks many variables present in an interactive shell. For instance, the
$PATH variable may not include directories where your scripts or binaries reside.
When using commands like
curl, you must specify the full path to the executable. If your script works manually but fails via cron, it is almost certainly because cron cannot find the binary. You can locate the full path using the
which command in your terminal. Replace relative paths with absolute ones in your crontab entry. For example, instead of just
curl https://example.com, use
/usr/bin/curl https://example.com.
Another critical factor is the user context. Cron jobs run as the user who owns the crontab file. If your script requires elevated privileges, you must edit the root crontab using
sudo crontab -e. Refer to our guide on
How to Properly Set sudo crontab to Backup Files with Superuser Rights Nightly for best practices when handling sensitive operations. Always ensure the script has executable permissions (
chmod +x script.sh) before adding it to the scheduler.
Checking System Logs for Errors
Cron does not output errors to your console by default; they are logged by the system. On most Linux distributions, these logs are stored in
/var/log/syslog or
/var/log/cron. To diagnose a failed job, filter these logs for entries related to
CRON. Use the following command to view recent cron activity:
grep CRON /var/log/syslog | tail -n 20
Look for lines indicating "CMD" which shows the command attempted to run. If you see no entries at all, the cron daemon might not be running, or the schedule is malformed. If you see entries but the task still fails, check for exit codes or error messages appended to the log. Many administrators redirect both standard output and standard error to a log file within the crontab line to capture runtime errors. Append
> /path/to/logfile.log 2>&1 to your command. This ensures that any stderr output is captured alongside stdout, providing crucial clues about permission denied errors or missing dependencies.
If the cron service itself is unresponsive, refer to
Troubleshooting Cron Service Failures: Why and How to Fix to restart the daemon and verify its status. A stopped service will silently ignore all scheduled tasks until restarted.
Debugging Script Execution Issues
Even with correct syntax and logging, scripts may fail due to environmental differences. Interactive shells load profile files like
.bashrc or
.profile, which set up aliases, functions, and variables. Cron does not source these files unless explicitly told to do so. If your script relies on specific environment variables, define them at the top of your crontab file before the job definitions. For example:
MAILTO=""
PATH=/usr/local/bin:/usr/bin:/bin
* * * * * /home/user/script.sh
Testing your script in a simulated cron environment can help identify issues. Run your script with a clean environment using
env -i bash --login -c 'your_command'. This mimics the minimal environment cron provides. If the script fails here, you know the issue is environmental rather than timing-related. Also, verify that the working directory is correct. Cron starts in the user's home directory by default. If your script expects to be in a specific folder, change directory explicitly within the command:
cd /path/to/dir && ./script.sh.
For more complex scenarios involving background processes or detached sessions, consider how cron interacts with session managers. See
Starting a Screen Sessions Upon Reboot and Executing a Script in It if your tasks require persistent terminal sessions.
Handling Dependencies and Resource Conflicts
Sometimes a job fails because another process is locking a resource or consuming excessive CPU. Check for zombie processes or runaway scripts that might have crashed previously. Use
ps aux | grep script_name to see if old instances are still running. If a previous run did not finish, subsequent scheduled runs might be skipped or queued depending on the implementation. Ensure your script exits cleanly with a status code of 0 upon success. Non-zero exit codes can trigger mail notifications if configured, but won't necessarily stop the next scheduled run unless you implement locking mechanisms.
If your cron job involves network requests, verify connectivity from the server's perspective. Firewalls or DNS issues might block
curl commands during specific times. Test the command manually at different times of day to rule out transient network problems. Also, check disk space. If the log file grows too large or the target directory fills up, subsequent writes will fail silently or throw errors. Implement log rotation policies to manage file sizes automatically.
Frequently Asked Questions
Why does my cron job work manually but not via crontab?
This is usually caused by a difference in the environment between your interactive shell and the cron environment. Ensure you use absolute paths for all commands and scripts. Also, verify that any required environment variables are defined either in the crontab file or sourced within the script itself.
How can I see the output of a cron job if it fails?
Redirect both standard output and standard error to a log file by appending
> /path/to/logfile.log 2>&1 to your crontab entry. Then, inspect the log file after the scheduled time to read any error messages or diagnostic output generated by the command.
What should I do if the cron daemon is not running?
Check the status of the cron service using
systemctl status cron or
service cron status. If it is inactive, start it with
sudo systemctl start cron. If it fails to start, consult system logs for initialization errors or refer to guides on troubleshooting cron service failures.
Can I run a cron job every minute?
Yes, you can set the minute field to
* to run a job every minute. However, be cautious of resource usage. Running heavy tasks every minute can overwhelm the system. Consider increasing the interval or optimizing the script to ensure it completes within the allotted time frame.
How do I handle timezone issues with cron jobs?
Cron uses the system's local timezone by default. If you need to run jobs in a specific timezone, set the
TZ environment variable in your crontab file. For example, add
TZ=America/New_York at the top of the crontab to ensure all schedules interpret times according to that zone.