cPanel Cron Jobs for Beginners: 7 Errors Solved

If you've ever needed to run a script every hour or clear cache automatically at midnight, you need a cron job. They're the Unix automation tool that runs commands on a schedule without you clicking anything. cPanel wraps cron in a simple form, but the errors beginners hit are the same whether you're in cPanel or typing into a terminal.

I'll define every piece, show you how to create your first working job, then walk through the seven errors I see in almost every support ticket about "my cron isn't working."

What is a cron job?

A cron job is a scheduled task. The name comes from chronos (time). The cron daemon—a background process on Linux—wakes up every minute, reads a table of jobs, and runs the ones whose schedule matches the current time.

Each job is one line: a schedule pattern, then the command to run.

Your shared hosting account has its own cron table (a "crontab"). cPanel gives you a web form to add entries to that table without SSHing in and editing it by hand.

Why you'd use a cron job

Common use cases:

• Run a PHP script to send daily email digests.
• Clear application cache every six hours.
• Pull fresh data from an API and save it to a database.
• Generate a sitemap at 3 AM when traffic is low.
• Archive old logs once a week.
• Renew an SSL certificate automatically (though Let's Encrypt hooks usually handle this).

Anything that needs to happen on a fixed schedule without you remembering to do it.

How to create your first cron job in cPanel

Log into cPanel and search for "Cron Jobs" in the search box, or find it under the Advanced section.

You'll see two parts: a form to add a new job, and a list of existing jobs below.

The schedule fields

The form shows five dropdowns or text boxes:

• Minute (0-59)
• Hour (0-23, in 24-hour time)
• Day (1-31)
• Month (1-12)
• Weekday (0-7, where both 0 and 7 mean Sunday)

An asterisk * in any field means "every." So * in the Minute field means every minute, * in the Hour field means every hour.

cPanel also offers "Common Settings" shortcuts like "Once Per Day" or "Twice Per Month," which pre-fill the five fields for you.

The command field

Below the schedule, you type the command to run. For a PHP script, the full line looks like:

/usr/bin/php /home/username/public_html/myscript.php

Replace username with your actual cPanel username and adjust the path to wherever your script lives.

Example: run a PHP script every day at 2 AM

1. Set Minute to 0.
2. Set Hour to 2.
3. Leave Day, Month, and Weekday as *.
4. In the Command box, type:
   bash /usr/bin/php /home/youruser/public_html/scripts/cleanup.php
5. Click Add New Cron Job.

You'll see it appear in the list below. That's it—your first cron job is live.

The seven errors beginners hit (and how to fix them)

Most tickets I handled boiled down to one of these.

1. The script runs but does nothing

Symptom: the cron email says the job ran, or you see an entry in the cron log, but the expected result didn't happen—no file was created, no database row inserted, nothing.

Cause: the script works when you visit it in a browser because the browser request sets $_SERVER variables, includes session data, or loads WordPress/Drupal context automatically. Cron runs the script as a standalone CLI process. No web server, no cookies, no $_POST data.

Many scripts assume they're being called via HTTP and break silently when run from the command line.

Fix:

• Open your script and make sure it doesn't depend on $_GET, $_POST, $_SERVER['HTTP_HOST'], or session variables.
• If it's a WordPress plugin script, you might need to load wp-load.php manually at the top:
  php <?php require_once('/home/youruser/public_html/wp-load.php'); // your code here
• Test the script from SSH first:
  bash /usr/bin/php /home/youruser/public_html/myscript.php
  If it fails or outputs errors, fix those before expecting cron to work.

2. Permission denied

Symptom: cron email says Permission denied or the script doesn't execute at all.

Cause: the script file isn't executable, or the ownership is wrong. When you upload via FTP as one user and cron runs as another, or when file permissions are set to 644 instead of 755, the cron daemon can't execute it.

Fix:

• For PHP scripts called with /usr/bin/php, the script doesn't need execute permission—it just needs to be readable.
• For shell scripts or binaries, set execute permission:
  bash chmod +x /home/youruser/script.sh
• Check ownership:
  bash ls -l /home/youruser/script.sh
  The user should match your cPanel username. If it doesn't, use cPanel File Manager to reset ownership, or SSH in and run:
  bash chown youruser:youruser /home/youruser/script.sh

3. Wrong PHP binary path

Symptom: cron email says command not found or /usr/bin/php: no such file or directory.

Cause: the PHP binary isn't where you think it is. Shared hosts often install PHP in /usr/local/bin/php or /opt/cpanel/ea-php81/root/usr/bin/php instead of /usr/bin/php.

Fix:

SSH into your account and run:

which php

That prints the actual path. Copy it exactly and use it in your cron command. For example:

/opt/cpanel/ea-php81/root/usr/bin/php /home/youruser/public_html/script.php

If you don't have SSH, ask your host or check cPanel's MultiPHP Manager to see which PHP version you're using, then look up the binary path in your host's documentation.

4. Relative paths break

Symptom: the script can't find a file it requires or includes. Error log shows failed to open stream: No such file or directory.

Cause: relative paths like require 'config.php' or include '../lib/db.php' resolve relative to the current working directory. When you run the script in a browser, the working directory is usually the script's own folder. When cron runs it, the working directory is your home directory (/home/youruser).

So config.php looks for /home/youruser/config.php instead of /home/youruser/public_html/config.php.

Fix:

Use absolute paths everywhere in the script:

require_once('/home/youruser/public_html/config.php');

Or derive the absolute path dynamically:

define('BASE_PATH', __DIR__);
require_once(BASE_PATH . '/config.php');

That way the script works whether called from the web or from cron.

5. Environment variables missing

Symptom: the script tries to read $_ENV['DATABASE_URL'] or relies on PATH containing a specific binary, and fails with "undefined variable" or "command not found."

Cause: cron runs with a minimal environment. It doesn't load your .bashrc or any shell profile, so environment variables you set interactively aren't available.

Fix:

Define variables directly in the cron command:

PATH=/usr/local/bin:/usr/bin:/bin DATABASE_URL=mysql://user:pass@localhost/db /usr/bin/php /home/youruser/script.php

Or have the script read from a .env file or a config file you know exists.

If your application depends heavily on environment variables, consider writing a wrapper shell script that sources the environment and then calls the PHP script:

#!/bin/bash
export DATABASE_URL="mysql://user:pass@localhost/db"
/usr/bin/php /home/youruser/public_html/script.php

Then point the cron job at that wrapper script.

6. No output, no email

Symptom: the cron job runs, but you never see any output or error message. You expect an email notification but nothing arrives.

Cause: by default, cron mails output only if there is output. If your script is silent (no echo, no error messages), cron sends no email. If your account's email address is not set or your server's mail delivery is broken, you won't receive the email even if cron tried to send it.

Fix:

• Set the email address at the top of cPanel's Cron Jobs page in the "Cron Email" field. Use an external address like Gmail if your domain's mail is having trouble.
• Make your script produce output so you know it ran. Add a line at the end:
  php echo "Cleanup completed at " . date('Y-m-d H:i:s') . "\n";
• Redirect output to a log file in the cron command itself:
  bash /usr/bin/php /home/youruser/script.php >> /home/youruser/logs/cron.log 2>&1
  The >> file.log appends standard output, and 2>&1 merges error output into the same file. Now check that log file to see what happened.

7. Wrong schedule syntax

Symptom: the job never runs, or runs at unexpected times.

Cause: you misunderstood how the five time fields work. For example, setting Minute to 5 and Hour to * means "every hour at five minutes past," not "every five minutes." Or you set both Day and Weekday to specific values, which can create confusing OR logic.

Fix:

Remember these common patterns:

• Every five minutes: Minute = */5, Hour/Day/Month/Weekday = *
• Every hour on the hour: Minute = 0, Hour = *, rest = *
• Every day at 3:30 AM: Minute = 30, Hour = 3, rest = *
• Every Monday at noon: Minute = 0, Hour = 12, Day = *, Month = *, Weekday = 1
• First day of every month at midnight: Minute = 0, Hour = 0, Day = 1, Month = *, Weekday = *

If you use both Day and Weekday, the job runs when either condition is true (it's an OR, not an AND). Usually you want one or the other, not both.

Test your schedule by setting it to run in the next few minutes and watching for the email or log entry.

How to test and debug a cron job

Don't wait 24 hours to find out if your daily cron worked.

1. Set a test schedule: change the time fields so the job runs two minutes from now.
2. Check email or logs: after the job should have run, check your inbox for cron output or look at the log file you redirected output to.
3. Run the command manually in SSH:
   bash /usr/bin/php /home/youruser/public_html/script.php
   If it works in SSH, it will work in cron (assuming you used absolute paths).
4. Check cPanel logs: some hosts log cron execution attempts in the cPanel error log or a dedicated cron log under "Metrics" or "Logs."

Once you confirm it works, change the schedule back to the real interval.

Common cron schedule examples

Here's a quick reference:

Schedule	Minute	Hour	Day	Month	Weekday
Every minute (testing only)	*	*	*	*	*
Every 10 minutes	*/10	*	*	*	*
Every hour at :15 past	15	*	*	*	*
Daily at 2:00 AM	0	2	*	*	*
Sundays at 5:00 AM	0	5	*	*	0
First of the month, midnight	0	0	1	*	*
Twice a day (6 AM and 6 PM)	0	6,18	*	*	*

You can also use ranges like 1-5 (Monday through Friday) or lists like 1,15 (first and fifteenth of the month).

What about WordPress cron?

WordPress has a pseudo-cron system called WP-Cron that runs scheduled tasks when someone visits your site. It's not a real cron job—it's triggered by page loads. On low-traffic sites, this means scheduled posts or plugin tasks may fire late or not at all.

Many hosts and performance guides recommend disabling WP-Cron and replacing it with a real cron job:

1. Add this line to wp-config.php:
   php define('DISABLE_WP_CRON', true);
2. Create a cron job in cPanel that runs every few minutes:
   bash */5 * * * * /usr/bin/php /home/youruser/public_html/wp-cron.php

Now WordPress tasks run on schedule even if no one visits your site.

What to check first when a cron fails

If your cron job isn't doing what you expect:

• Run the exact command manually in SSH. If it fails there, the problem is the script, not cron.
• Check that you used the correct PHP binary path with which php.
• Use absolute paths in your script for all file operations.
• Make sure the script doesn't depend on web-only variables like $_GET or $_SERVER['HTTP_HOST'].
• Redirect output to a log file so you can see errors: >> /home/user/cron.log 2>&1.
• Verify the schedule fields match your intent—test with a run two minutes away.
• Confirm file permissions allow the cron user to read or execute the script.

Nine times out of ten, one of those seven errors is the culprit. Fix it, test, and you're done.

Related posts

• 9 Core Web Vitals Mistakes That Kill Performance (2026)
• NVMe SSD Hosting Performance: 4X Faster Benchmarks
• Core Web Vitals Optimization: 8 Fixes That Work
• VPS vs Shared Hosting: 5 Signs You Need to Upgrade