Why Isn't Your Cron Job Running? How to Troubleshoot Common Cron Job Problems

If a cron job isn't running when you expect it to, the problem is almost always one of a few common causes: a mistyped command, a missing file path, or a schedule that doesn't mean what you think it means. You can usually find and fix the issue yourself without contacting support, by working through a short checklist.

Start by Checking If the Cron Job Actually Ran

Before assuming the job failed, confirm whether it ran at all. Cron jobs normally send an email to your account's contact address every time they run, with any output or error message included. Check that inbox first: if you're not receiving these emails, you may have turned them off, or the job may genuinely not be running.

If your inbox is flooded with cron output emails for a job that runs often, that's a separate (and easy to fix) problem. It still confirms the job is running, just noisily.

Common Causes and How to Fix Them

1. The Command Uses a Relative Path

Cron does not run your command from your website's folder the way you might expect. If your command refers to a script using a relative path like php script.php, it will fail because cron doesn't know where to look. Always use the full, absolute path to both the program and the script, for example:

• /usr/bin/php /home/yourusername/public_html/script.php

You can find your home directory path by checking your account's file manager, or by adding pwd as a quick test command in a cron job and reading the output email it sends you.

2. The Schedule Fields Are in the Wrong Order or Wrong Value

Cron schedules use five fields in a fixed order: minute, hour, day of month, month, and day of week. A common mistake is mixing up hour and minute, or setting a day-of-week value incorrectly (0 and 7 both mean Sunday). Double-check each field against your control panel's cron job form, which usually shows labeled fields rather than making you type the raw schedule string.

• Setting the minute field to * instead of a specific number makes the job run every minute, not once a day.
• Using */60 in the minute field is invalid; use 0 with a specific hour instead.

3. The Script Has a PHP or Permissions Error

If the command path and schedule are correct but the job still fails, the script itself may be erroring out. Check the output email cron sends after each run; it usually includes the exact error message. A common cause is the script file not being executable, or being owned by the wrong user. Make sure the file has the correct read/execute permissions set in File Manager.

4. You're Using the Wrong PHP Version or Binary

If your script needs a specific PHP version, calling the system default PHP binary with just php may run an older or newer version than your code expects. Use the full path to the correct PHP version's binary, which your hosting account's PHP settings page will usually show you, or ask which path to use for your current PHP version.

Checking Cron Job Logs

In cPanel

1. Log in to cPanel and open Cron Jobs.
2. Review the list of Current Cron Jobs at the bottom of the page to confirm the schedule and command are exactly what you intended.
3. Check the email account that receives cron output (shown at the top of the Cron Jobs page) for the most recent run's result.
4. If you have SSH or Terminal access, you can also check the system cron log for extra detail on whether the job fired at all.

In DirectAdmin

1. Log in to DirectAdmin and open Cron Jobs under the Advanced Features section.
2. Confirm the schedule fields and command match what you expect, directly in the cron job list.
3. Check the notification email address configured for cron jobs for the output of the last run.
4. If the job still isn't firing, remove it and recreate it from scratch. A corrupted or malformed entry can sometimes prevent the whole crontab from being read correctly.

Still Not Working?

If you've confirmed the path, command, permissions, and schedule are all correct and the job still doesn't run, open a support ticket with the exact command you're using and a copy of the error email, if you received one. That lets support pinpoint the issue quickly instead of repeating the same checks.