Troubleshooting 'Cron Job Not Running': A Comprehensive DevOps Guide
Fix 'cron job not executing' errors on Ubuntu, Debian, EC2, Magento, and WordPress. Step-by-step diagnostic and resolution guide for crontab failures.
- Cron executes commands with a minimal environment; missing PATH variables are the #1 cause of scripts working in the terminal but failing in cron.
- Permission issues, incorrect file ownership, or lack of executable flags on target scripts frequently block cron jobs from executing.
- A missing trailing newline in the crontab file will silently prevent the last job from running.
- Quick Fix: Redirect stderr and stdout to a log file (`>> /var/log/cron.log 2>&1`) to expose silent failures immediately.
| Method | When to Use | Time | Risk |
|---|---|---|---|
| Syslog / Journalctl Review | Initial diagnosis to check if the cron daemon even attempted to trigger the job. | 1-2 mins | None |
| Output Redirection | When the job triggers but fails silently. Captures script-level errors. | 2-5 mins | Low |
| Environment Replication | When commands work interactively but fail in cron (e.g., 'command not found'). | 5-10 mins | Low |
| App-Specific Debugging (Magento/WP) | When system cron runs but application tasks (like 'magento cron:run') fail. | 10-20 mins | Medium |
Understanding the Error: Why Do Cron Jobs Fail?
The frustration of setting up a scheduled task only to find that your cron job is not running is a rite of passage for every developer and sysadmin. When a task executes flawlessly in your terminal but fails silently in the background, the disconnect lies in how the cron daemon handles execution.
Unlike an interactive SSH session, cron does not source your ~/.bashrc or ~/.profile. It runs in an extremely stripped-down environment. This is why a linux cron not running issue is rarely a bug in the daemon itself, but rather a mismatch between your script's expectations and the actual execution environment.
Common error manifestations include:
bash: <command>: command not foundin local mail.- Silent failures where nothing happens and no logs are generated.
Permission deniederrors.- Application-specific stalls, such as
magento cron jobs not runningorwordpress cron job not working.
Step 1: Diagnose the Failure
Before changing any configuration, you must isolate the failure point. Did cron fail to trigger the job, or did the script fail during execution?
1. Check the Cron Daemon Status
First, verify that the daemon is active. On ubuntu crontab not running or debian crontab not running scenarios, the service is called cron. On RHEL/CentOS/EC2 Amazon Linux, it is crond.
systemctl status cron
# or
systemctl status crond
If it's inactive, start and enable it: sudo systemctl enable --now cron.
2. Inspect the Syslog Cron logs its scheduling actions to the system log. Check if your job was triggered at the expected time.
grep CRON /var/log/syslog
# On systems using journald:
journalctl -u cron
Look for entries like (root) CMD (/path/to/script.sh). If you see this, cron is working; your script is failing.
3. Capture Silent Errors By default, cron emails the standard output (stdout) and standard error (stderr) to the user owning the crontab. If no mail server is configured, this output is lost. Modify your crontab to redirect output to a file:
* * * * * /path/to/your/script.sh >> /tmp/cron_debug.log 2>&1
Wait for the next execution and read /tmp/cron_debug.log. This single step resolves 80% of crontab not working mysteries.
Step 2: The Most Common Root Causes and Fixes
Root Cause A: The Minimal Environment (PATH Issues)
When you type node or php in your terminal, the shell knows where to find them because of your $PATH variable. Cron's default PATH is typically just /usr/bin:/bin. If your script relies on /usr/local/bin/node or /opt/homebrew/bin/python, it will fail with command not found.
The Fix: Always use absolute paths in your cron jobs and scripts (e.g., /usr/bin/php /var/www/script.php). Alternatively, declare your PATH at the top of your crontab file:
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
* * * * * my_script.sh
Root Cause B: Permissions and Ownership
If crontab not executing is your symptom, check file permissions. The script must be executable.
chmod +x /path/to/script.sh
Additionally, if the cron job is in a user's crontab (crontab -e), that user must have read and execute permissions on all files and directories the script interacts with. If you are manipulating system files, the job must be in the root crontab (sudo crontab -e) or /etc/crontab.
Root Cause C: The Missing Trailing Newline Cron strictly requires that every line, including the last one, ends with a newline character. If your file ends immediately after the last character of your command, cron will completely ignore that line. Always press 'Enter' at the end of your crontab file before saving.
Root Cause D: Relative Paths in Scripts
Cron executes scripts from the user's home directory by default. If your script contains cat data.txt, it will look in /home/user/data.txt, not the directory where the script resides.
The Fix: Use absolute paths inside your scripts, or cd into the directory first:
* * * * * cd /path/to/app && ./script.sh
Step 3: Application-Specific Cron Issues
WordPress Cron Job Not Working
WordPress uses a virtual cron (wp-cron.php) that only triggers when someone visits the site. For low-traffic sites, scheduled posts and backups will fail. To fix this, disable virtual cron in wp-config.php:
define('DISABLE_WP_CRON', true);
Then, add a real system cron job to hit the endpoint:
*/5 * * * * curl -s https://yourdomain.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1
Magento 2 Cron Not Running
Magento heavily relies on cron for indexing, emails, and cache management. If magento cron jobs not running appears in your admin panel, verify that the cron is configured for the exact PHP CLI version used by Magento, and that it runs as the correct file system owner.
* * * * * /usr/bin/php /var/www/magento2/bin/magento cron:run | grep -v "Ran jobs by schedule" >> /var/www/magento2/var/log/magento.cron.log
CyberPanel / Control Panel Cron Issues
If a cyberpanel cron job not working issue arises, ensure you are creating the cron job under the correct user container. Often, control panels create isolated environments. Using the panel's GUI to create the cron job is highly recommended over manually editing /var/spool/cron/crontabs to avoid breaking configuration sync.
Frequently Asked Questions
# --- Diagnostic Commands ---
# 1. Check if cron daemon is running
systemctl status cron # Ubuntu/Debian
systemctl status crond # RHEL/CentOS/Amazon Linux EC2
# 2. View cron execution logs
grep CRON /var/log/syslog
journalctl -u cron --since "1 hour ago"
# 3. Check if your script is executable
ls -la /path/to/your/script.sh
# If missing 'x', fix it:
chmod +x /path/to/your/script.sh
# --- Crontab Best Practices (Run 'crontab -e') ---
# Define PATH and SHELL explicitly at the top of the crontab
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# BAD: Fails silently, relative paths, relies on unknown environment
# * * * * * node myapp.js
# GOOD: Absolute paths, redirects both stdout and stderr to a log file for debugging
* * * * * /usr/bin/node /opt/myapp/myapp.js >> /var/log/myapp_cron.log 2>&1
# GOOD: Change directory before executing so relative paths inside the script work
*/5 * * * * cd /opt/myapp && ./backup.sh >> /var/log/backup.log 2>&1Error Medic Editorial Team
The Error Medic Editorial Team consists of senior Site Reliability Engineers and DevOps practitioners dedicated to demystifying Linux infrastructure, automation, and server troubleshooting.