cPanel Hosting

Setting Up Cron Jobs in cPanel — Scheduled Tasks Guide

How to set up cron jobs in cPanel — schedule syntax, real-world examples for WordPress and custom scripts, and the gotchas that catch most people.

4 min read

A cron job runs a command on a schedule — every 5 minutes, every Sunday at 3 AM, the first of every month. They’re how you automate tasks that need to happen without you logging in: WP-Cron offloading, backup scripts, log rotation, content publishing, anything time-based. cPanel’s interface for cron jobs is straightforward once you understand the schedule format.

Where to set them up

cPanel → Advanced → Cron Jobs. You’ll see two sections: Common Settings (presets like “Once per hour”) and Add New Cron Job (full control).

Set your email at the top so you get notifications when cron jobs fail (or succeed loudly). Most people set this to /dev/null on jobs they don’t want notifications for — see the examples below.

The 5 fields of a cron schedule

FieldRangeExamples
Minute0–590 = on the hour, */5 = every 5 min
Hour0–233 = 3 AM, * = every hour
Day of month1–311 = first of month, * = every day
Month1–12* = every month
Day of week0–6 (Sun=0)1 = Monday, * = every day

Common schedule patterns

WhenSchedule (minute hour day month dayofweek)
Every 5 minutes*/5 * * * *
Every 15 minutes*/15 * * * *
Every hour, on the hour0 * * * *
Every day at 3:00 AM0 3 * * *
Every Sunday at 4:00 AM0 4 * * 0
First day of every month at midnight0 0 1 * *
Weekdays at 9:30 AM30 9 * * 1-5

cPanel’s Common Settings dropdown fills these in for you — useful when you don’t remember the syntax. Custom intervals (every 3 minutes, twice a day) need manual entry.

Real-world cron examples

Replace WordPress’s WP-Cron with real cron

WP-Cron runs on every page load — under high traffic it duplicates work; under no traffic it doesn’t run at all. The fix:

  1. Edit wp-config.php, add: define('DISABLE_WP_CRON', true);
  2. Add a cron job in cPanel:
Schedule: */5 * * * *
Command:  wget -q -O - https://yourdomain.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

The >/dev/null 2>&1 at the end discards output — without it, cPanel emails you every 5 minutes.

Daily database backup to a file

Schedule: 0 2 * * *
Command:  mysqldump -u DBUSER -pDBPASS DBNAME > ~/db-backup-$(date +%Y-%m-%d).sql 2>&1

Replace DBUSER, DBPASS, DBNAME with your real values. Files land in your home directory with date stamps. Note the escaped % — cron treats % as a newline unless escaped.

Weekly cleanup of old log files

Schedule: 0 4 * * 0
Command:  find ~/logs -type f -name "*.log" -mtime +30 -delete

Deletes log files older than 30 days every Sunday at 4 AM. Prevents disk fill from accumulated logs.

Hit a custom script

Schedule: 0 */6 * * *
Command:  /usr/local/bin/php -q /home/USER/public_html/scripts/sync.php >/dev/null 2>&1

Replace USER with your cPanel username. Runs the PHP script every 6 hours. Always use the full PHP path — php alone may not be in cron’s PATH.

The 5 cron gotchas

  • Server timezone, not yours. Cron schedules use the server’s timezone. Verify at cPanel → Server Information (or run a one-time cron that prints date to a file). Adjust schedules accordingly.
  • PATH is minimal. Cron’s environment doesn’t include your shell’s PATH. Always use full paths for commands: /usr/local/bin/wget not wget, /usr/local/bin/php not php.
  • % needs escaping. A literal % in cron is treated as a newline. Escape as % when using date formats.
  • Output gets emailed. Any stdout/stderr triggers an email. Append >/dev/null 2>&1 to silence success; pipe to a log file (>> ~/cron.log 2>&1) to capture without emailing.
  • Frequency limits. Most iWebVault shared plans cap cron at “every 5 minutes”. Faster than that (every minute, every 2 minutes) is reserved for VPS / dedicated.

Verifying a cron job is running

After saving, three ways to check it works:

  • Logs. cPanel → Metrics → Errors sometimes catches failed cron invocations. Also ~/logs/ for any output you redirected.
  • Email. Don’t redirect output for the first run, run on a 1-minute schedule, watch for the cPanel-sent email. After confirming it works, add >/dev/null back.
  • Side effect. If your script creates a file, writes to a database, sends an email — verify that effect happened. Most reliable confirmation.

Common cron problems

“Cron set up but never runs.” Almost always wrong command path. SSH in (if available) and try running the exact command manually; whatever errors out is what cron is silently failing on too.

“Cron job emails me constantly.” You haven’t suppressed output. Add >/dev/null 2>&1 at the end of the command.

“WordPress scheduled posts aren’t publishing.” WP-Cron isn’t running (no traffic, or DISABLE_WP_CRON set without a real cron job). Set up the real cron job above.

“Cron runs but doesn’t do what I expect.” Working directory and environment are different from your shell. Use absolute paths everywhere, including in any files the script reads or writes.

“Can I run a cron more frequently than every 5 minutes?” Not on shared hosting. If you genuinely need sub-5-minute granularity (real-time sync, queue workers), VPS is the right tier — see choosing a plan.

What’s next

Cron is one of those tools you set up once for each task and then forget about. Once you have your “real” WP-Cron, daily DB backup, and weekly log cleanup running, 90% of what most sites need from cron is done.

Was this helpful?