Skip to main content
A cron job runs a command on a schedule. On web hosting, the usual uses are a CMS scheduler, a backup script, or a periodic import — anything that must happen without someone clicking a button.
Prerequisites
  • A Web Hosting service with OnetSolutions
  • Access to your cPanel account
  • The command you want to run, and the absolute path to it

​
Creating a Cron Job

1

Log in to cPanel

Access your cPanel account through the OnetSolutions dashboard.
2

Open Cron Jobs

In the “Advanced” section, click “Cron Jobs”.
3

Set a notification address

In “Cron Email”, enter the address that should receive the output. Leave it set while you are testing — the output is how you find out the job failed.
4

Choose the schedule

Use “Common Settings” for a standard interval, or fill the five fields individually for anything else.
5

Enter the command

Give the full command with absolute paths, then click “Add New Cron Job”.

​
Understanding the Schedule

The five fields, in order:
Common schedules:

​
Writing the Command

Cron runs with a minimal environment. It does not know your shell aliases, and it does not necessarily resolve php to the version your site uses. Use absolute paths for both the interpreter and the script:
To keep a log of what happened rather than relying on email:
The 2>&1 is what captures errors. Without it the log records the successful output and silently drops the failures, which is the opposite of useful. To run a job silently once it is proven, discard the output:
Do not set a job to run every minute unless it genuinely needs to. Overlapping runs of a slow script pile up, consume the account’s resources, and can take the site down on their own. If a job might run long, have the script exit early when a previous run is still active.

​
WordPress and Similar CMSs

WordPress schedules its own tasks through wp-cron.php, triggered by visitor traffic. On a low-traffic site, that means scheduled posts and backups fire late or not at all. The usual fix is to disable the traffic-driven trigger and run it from cron instead:

​
Troubleshooting

Check the paths first: a command that works when you type it in a terminal often fails under cron because it relied on your shell environment. Use absolute paths everywhere, including the interpreter.
Redirect the output to a log with >> /path/to/cron.log 2>&1 and read it after the next run. A script that fails on a missing file or a database connection says so there.
Cron emails any output, including normal output. Once the job is proven, append > /dev/null 2>&1 to silence it, or clear the “Cron Email” field.
Cron follows the server’s timezone, which may not be yours. Work out the schedule in server time, and remember that daylight saving shifts it twice a year.
Test the command manually before scheduling it. A cron job that fails silently at 03:00 is far harder to diagnose than the same command failing in front of you.