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
| Field | Range | Examples |
|---|---|---|
| Minute | 0–59 | 0 = on the hour, */5 = every 5 min |
| Hour | 0–23 | 3 = 3 AM, * = every hour |
| Day of month | 1–31 | 1 = first of month, * = every day |
| Month | 1–12 | * = every month |
| Day of week | 0–6 (Sun=0) | 1 = Monday, * = every day |
Common schedule patterns
| When | Schedule (minute hour day month dayofweek) |
|---|---|
| Every 5 minutes | */5 * * * * |
| Every 15 minutes | */15 * * * * |
| Every hour, on the hour | 0 * * * * |
| Every day at 3:00 AM | 0 3 * * * |
| Every Sunday at 4:00 AM | 0 4 * * 0 |
| First day of every month at midnight | 0 0 1 * * |
| Weekdays at 9:30 AM | 30 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:
- Edit
wp-config.php, add:define('DISABLE_WP_CRON', true); - 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
dateto 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/wgetnotwget,/usr/local/bin/phpnotphp. - % 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>&1to 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/nullback. - 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
- Resource impact of crons: cPanel resource limits.
- Backup automation: JetBackup 5 backups and restore.
- Database backups: phpMyAdmin and databases.
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?
Thanks for your feedback!