Record the expected run time, server timezone, full command and application’s own last-run status. Keep the existing entry available for comparison. Check whether another scheduler, such as an application queue worker, already performs the same work.

1. Open Cron Jobs and inspect all five schedule fields and the exact command. Confirm the interval means what you intend in the server’s timezone.
2. Use absolute paths for the interpreter and script. Check that the script exists under the expected account and has the permissions required for its execution method.
3. Enable useful output delivery or redirect output to a private diagnostic log temporarily. Do not hide both output streams while investigating.
4. Run the application’s safe diagnostic command as the same account where appropriate. Avoid manually repeating a billing or mail-sending job unless its documentation says the operation is safe to repeat.
5. Wait for the next scheduled run and compare the cron output with the application’s last-run timestamp and resulting work.

A successful result has evidence that the scheduler invoked the command and that the application completed the intended task. Check processed items, not just an empty output message.

If no invocation evidence exists, provide support the schedule and timestamp for server-side review. If invocation occurs but work fails, inspect runtime paths, configuration and application errors rather than recreating the cron entry.

No. Many successful commands produce no output. Conversely, a cron email can contain an error. Use an explicit application status or a controlled diagnostic log to distinguish these cases.

• Creating a scheduled cron task in cPanel
• Keeping useful cron logs without filling the hosting account
• Fixing a cron job that works only from an interactive shell
• Choosing the correct PHP executable for a cron job

• cPanel: Cron Jobs
• man7.org: Crontab