If your DirectAdmin cron job is not working, you are not alone. Cron failures are one of the most frustrating issues hosting administrators face — the job appears to be set up correctly, yet nothing runs. Silent failures, wrong PHP paths, broken permissions, and misconfigured environment variables are the usual culprits. This guide walks you through every known cause and fix, from basic setup verification to advanced debugging techniques that experienced sysadmins use.
How DirectAdmin Cron Jobs Work
DirectAdmin cron jobs are managed through the system's cron daemon (crond), which reads per-user crontab files stored under /var/spool/cron/. When you create a cron job through the DirectAdmin panel (Advanced Features → Cron Jobs), DirectAdmin writes the entry into that user's crontab file.
The key difference from cPanel is that DirectAdmin cron jobs run from the user's home directory (/home/username/), not from public_html. Scripts that rely on relative paths will break because the working directory is not what most developers expect.
Cron jobs also run in a minimal shell environment. The full user PATH is not available. Commands like php, python, or wp must be referenced by their full absolute path, or cron will report "command not found" — silently, unless you have output logging set up.
💡 None of these worked? Skip the guesswork.
Get Expert Help →Step 1: Verify the Cron Job Is Actually Saved
Log into DirectAdmin → Advanced Features → Cron Jobs. Confirm your entry appears with the correct schedule fields (minute, hour, day, month, weekday) and command. If the interface shows the job but it does not appear to run, the issue is in the command itself, not the schedule.
crontab -l -u usernameReplace username with the DirectAdmin account username. If the cron entry is missing here, it was not saved correctly. Re-add it through the panel or directly with crontab -e -u username.
systemctl status crond
# or on older systems:
service crond statusIf crond is stopped, all cron jobs on the server will fail silently. Start it with:
systemctl start crond
systemctl enable crondwhich php
# Common results:
# /usr/local/bin/php
# /usr/bin/php
# /opt/cpanel/ea-php82/root/usr/bin/phpIf you are running multiple PHP versions via CustomBuild, list them all:
ls /usr/local/php*/bin/phpWrong:
* * * * * php /home/username/public_html/cron.phpCorrect:
* * * * * /usr/local/bin/php /home/username/public_html/cron.php*/5 * * * * /usr/local/bin/php /home/username/public_html/wp-cron.php > /dev/null 2>&10 * * * * /usr/bin/python3 /home/username/scripts/task.py >> /home/username/cron.log 2>&1Modify your cron command to append both stdout and stderr to a log file:
30 2 * * * /usr/local/bin/php /home/username/public_html/cron.php >> /home/username/cron_debug.log 2>&1After the next scheduled run, check the log:
cat /home/username/cron_debug.logIn the Cron Jobs panel, enter your email address in the "Send all Cron output to email" field. Cron will email you the output of every run. Note: this only works if cron output is not being redirected to /dev/null.
Always test your cron command by running it directly in the terminal as that user before trusting cron to run it:
su - username -c "/usr/local/bin/php /home/username/public_html/cron.php"If it fails here, you have found your problem. Fix the command before adding it to cron.
chmod 755 /home/username
chmod 755 /home/username/public_html
chmod 644 /home/username/public_html/cron.phpchmod 755 /home/username/scripts/backup.shls -la /home/username/public_html/cron.phpThe file should be owned by the DirectAdmin username, not root. Fix with:
chown username:username /home/username/public_html/cron.phpPATH=/usr/local/bin:/usr/bin:/bin
30 2 * * * php /home/username/public_html/cron.phpAdd this line before your cron entries via crontab -e -u username.
HOME=/home/username
PATH=/usr/local/bin:/usr/bin:/bin
* * * * * /usr/local/bin/php /home/username/public_html/task.phpScripts that use include('../config.php') will fail in cron because the working directory is /home/username/, not /home/username/public_html/. Fix by using absolute paths in your PHP:
<?php
define('BASE_PATH', '/home/username/public_html/');
include(BASE_PATH . 'config.php');
?>*/10 * * * * /usr/bin/wget -q -O /dev/null "https://yourdomain.com/cron.php?key=secret"Unquoted URLs with & parameters get truncated by the shell. Always wrap the URL in quotes:
*/5 * * * * /usr/bin/curl -s "https://yourdomain.com/wp-cron.php?doing_wp_cron" > /dev/null 2>&1# Test manually first:
curl -v "https://yourdomain.com/cron.php"
# If SSL fails, add --insecure (for internal scripts only):
curl -s --insecure "https://localhost/cron.php"grep CRON /var/log/cron | tail -30grep CRON /var/log/syslog | tail -30journalctl -u cron --since "1 hour ago"
# or for crond:
journalctl -u crond --since "1 hour ago"If the log shows the job triggering but it produces no result, the problem is in the script or environment. If the log shows no trigger at all, crond is not running or the crontab entry has a syntax error.
# Check for syntax issues:
crontab -l -u username | grep -v "^#" | grep -v "^$"Common syntax error: using */1 instead of * for "every minute", or missing a field in the five time fields.
In DirectAdmin admin panel → User Management → click the username → Account Configuration. Verify "Cron Jobs" is set to yes. If it is set to no, the user cannot create cron jobs at all — the entry simply does not get saved.
Resellers may have limited the number of cron jobs available to a user. Navigate to Reseller Level → Manage User Packages and verify the cron job limit is not set to 0.
Cron Job Not Sending Email Output
If you configured cron to email you output but emails are not arriving:
- Make sure your cron command does NOT redirect to
/dev/null— that suppresses all output including email - Cron only emails when there is output — a job that runs silently sends nothing
- Check spam folders — DirectAdmin sends from the system's
root@hostnameaddress - Verify the server's local mail delivery is working:
echo "test" | mail -s "cron test" your@email.com - The error "Cron emails can only be locally delivered" means your SMTP relay is blocking outbound cron mail — use local delivery or set
MAILTO=""to suppress
Quick Reference: Cron Job Troubleshooting Checklist
- ✅ crond service is running (
systemctl status crond) - ✅ Cron entry exists in
crontab -l -u username - ✅ Command uses full absolute path to interpreter (
/usr/local/bin/php) - ✅ Script file exists and is readable
- ✅ Permissions: directories 755, scripts 644 (PHP) or 755 (shell)
- ✅ File ownership matches username, not root
- ✅ Command tested manually via SSH as the user and works
- ✅ Output redirected to log file for debugging (
>> /home/username/cron.log 2>&1) - ✅ URLs are quoted if they contain & parameters
- ✅ Cron Jobs feature is enabled in the DirectAdmin account configuration
For persistent cron failures on a managed server, or if you need to set up complex scheduled task automation across multiple DirectAdmin accounts, CloudHouse Technologies' server management service provides expert hands-on support to diagnose and resolve cron issues fast.