How to set up a cron job

Cron is the standard way a Linux-based hosting account runs something automatically on a schedule, without you triggering it by hand or leaving a browser tab open. Nightly maintenance, a periodic data import, sending a scheduled report, clearing out old temporary files — anything that needs to happen "every night at 2am" or "every fifteen minutes" is a cron job.

Reading cron syntax

A cron schedule is five fields, each representing a unit of time, in a fixed order:

minute  hour  day-of-month  month  day-of-week
  *      *        *          *         *

An asterisk in a field means "every value" for that field. So working through some real examples:

0 2 * * *        Every day at 2:00am
*/15 * * * *     Every 15 minutes, all day, every day
0 0 1 * *        At midnight on the 1st of every month
30 6 * * 1       At 6:30am every Monday
0 */6 * * *      Every 6 hours, on the hour

The */15 and */6 forms are step values — "every 15th minute" and "every 6th hour" — and are the usual way to express "every so often" without listing out every individual value.

Setting one up in your control panel

Open the section of your control panel dealing with scheduled tasks or cron jobs. You will generally be asked for two things: the schedule, entered either as the five raw fields or picked from simplified dropdowns that build the same thing for you, and the command or URL to run.

A common example, calling a PHP script directly rather than through a URL:

php /home/youraccount/public_html/scripts/cleanup.php

Testing that it actually runs

Do not assume a saved cron job is a working cron job. Confirm it:

• Have the script log something. Even a single line written to a text file with a timestamp each time it runs gives you proof, and a record of exactly when it last fired.
• Check for an email notification, if your control panel offers one for cron output — many will send you the script's output, or any errors, by email if you provide an address.
• Set a short interval temporarily. If you are testing a job meant to run daily, set it to run every few minutes first, confirm it works, then change it to the real schedule. This turns a day of waiting into a few minutes of testing.

Common mistakes

• Wrong file path. The path has to be the full path on the server, not a path relative to somewhere else — copy it from your file manager or FTP client rather than guessing.
• Assuming a script has web-only dependencies satisfied. A script written assuming it is loaded through a normal page request may behave differently when triggered by cron, particularly around session handling or the working directory it expects to run from.
• Scheduling too frequently for what the job actually does. A heavy script running every minute can add unnecessary load to your account; match the frequency to how often the task genuinely needs to happen.
• Forgetting it exists. A cron job set up for a one-off need and never removed can keep running indefinitely. Review your scheduled tasks occasionally and delete anything you no longer need.

If you use WordPress

WordPress has its own internal approximation of cron, called WP-Cron, which does not run on a real schedule at all — it only fires when a visitor loads a page, which is unreliable on a quiet site. If you are relying on scheduled WordPress tasks such as publishing a post at a set time or running a plugin's maintenance job, a real server-level cron job calling into WordPress on a fixed schedule is more dependable. See replacing WP-Cron with a real cron job for how to set that up specifically.