Support Start > Web Hosting Technical Information > Cron Jobs

This page is showing a generic answer.
To see a more detailed answer customized for you, type your domain name here:

The Unix operating system we use offers a feature called “cron jobs”. A “cron job” is a task that runs a script at regular intervals on your web server.

Advanced users can use cron jobs with any of our hosting plans. On this page:

• How to set up a cron job
• Loading web pages from cron jobs
• Mail from cron jobs
• Removing cron jobs
• Cron job policies
• Using a cron job to backup your MySQL databases

How to set up a cron job

To set up a cron job, you'll make an SSH connection to your web server and type this command:

crontab -e

By default, the “nano” text editor is used when editing cron jobs. When editing cron jobs in nano, you should use the “down arrow” on your keyboard to scroll to the bottom of the existing text, then add your lines there.

You can save your changes by pressing ctrl+o — that’s the “control” or “ctrl” key on your keyboard, plus the lowercase letter “o” key, at the same time — then pressing ENTER. Similarly, ctrl-x will exit (quit) the editor.

A full description of how to use cron jobs is beyond the scope of this page (and in most cases, any script that instructs you to set up a cron job will tell you exactly how to do it) — but if you really want the gory details, type these two commands after logging in:

man 1 crontab
man 5 crontab

Many sites on the Internet have tutorial pages explaining how to use cron jobs, including Admin's Choice and Wikipedia.

Searching for “crontab” in your favorite search engine will turn up many more pages if you have questions.

Loading web pages from cron jobs

Cron jobs usually run scripts on the server's disk, just as if you'd typed the cron command in your home directory. Cron jobs don't load web pages (at least not without extra effort).

Occasionally, it may be necessary for a cron job to load a web page. For example, let's say you have a PHP 5 script that runs when you load this web page:

http://www.example.com/cron.php

If you want to run that script in a cron job at 20 minutes past every hour, one way to do it is to figure out which command you would type on the command line (knowing the disk-based path to your web directory or home directory will help) and make the cron entry match, like one of these examples:

20 * * * *  cd /home/ex/example.com; /usr/bin/php cron.php

20 * * * *  cd /var/www/html/ex/example.com; /usr/bin/php cron.php

However, “/usr/bin/php” won’t necessarily run your script in exactly the same way it would be run when loaded as a web page, so it may be better to load the URL as a web page for consistency. You can use the /usr/bin/wget program in your cron job entry, like this:

20 * * * *  /usr/bin/wget --quiet -O - 'http://www.example.com/cron.php'

Keep in mind that each cron job must be entered entirely on a single line, and be sure you don't enter any carriage returns between parts of the line.

Mail from cron jobs

If a cron job displays any text when it runs, that text will be emailed to the administrative contact we have on file for the account each time the cron job runs.

If you want the text sent to a different address, put this line before any other lines in your crontab file:

MAILTO = address@example.com

(Specifying the actual address you want instead of “address@example.com”, of course.)

If you want it to send mail to multiple addresses, you can create a forwarding address like “cron-forwarding@example.com” that forwards to as many addresses as necessary, then use this in your crontab:

MAILTO = cron-forwarding@example.com

It's also possible to completely suppress the mailing of output from a cron job with this line (again, before any other lines):

MAILTO = ""

However, we don’t recommend doing this because if your script stops working properly and starts emitting error messages, you’ll never see them (and there’s no way to go back and review the output if you do this).

A better approach is to modify your script so that it does not print any output when it works correctly, but still prints an error when something goes wrong. If that’s not possible, you may want to filter the cron messages into a separate folder of your mail program and delete them a few days later: that way, if something goes wrong, you can look back over the last few cron messages and see what happened.

Removing cron jobs

To completely disable all your cron jobs, make an SSH connection to your Web server and use this command:

crontab -r

If you have multiple cron jobs — that is, you have multiple lines in your crontab — and you just want to remove one of the jobs, use “crontab -e” instead and delete the appropriate line.

Cron job policies

We have a few commonsense policies about cron jobs:

• Cron jobs are intended only for time-sensitive tasks that absolutely must be performed at certain times or intervals. Don't use them for tasks that could be performed without cron.
• Your cron job shouldn't run more often than necessary for the task. We recommend running cron jobs no more than once per hour; if you must run them more often, please choose the lowest possible frequency. Never schedule more than one cron job every five minutes (cron jobs set to run more often will be automatically reset to run every five minutes).
• Your cron jobs should use a reasonable amount of resources. At the very most, a job should use no more than one second of “CPU time” for every minute apart that it's scheduled, with a 60 second maximum no matter how far apart they're scheduled. For example, a cron job that runs every five minutes should not take more than five seconds of CPU time to finish, a job that runs every 30 minutes should take no more than 30 seconds, and a job that runs once per hour (or even once per day) should not run for more than 60 seconds. CPU time use by cron jobs counts towards normal script CPU usage limits.
• You shouldn't absolutely count on your cron job running. For example, if the server your website is on is being restarted for scheduled maintenance at the time the job is scheduled to run (which is rare but could happen), the job simply won't run until the next time it's scheduled. Make sure your systems can properly handle the cron job being occasionally skipped.
• Schedule cron jobs for a random number of minutes past the hour, rather than running them at the “top of the hour”. This makes sure that everyone's cron jobs don't all try to run at the same time and cause hourly load spikes. We may alter the exact minute that your cron job runs if necessary to balance the load on a server — for example, if you specify something like "*/10" as the minute field, we may change it to something like "2-59/10". That still runs 6 times per hour, but runs each one two minutes later than "*/10" would.

Using a cron job to backup your MySQL databases

We're often asked if it's possible to use cron jobs to make MySQL database backups. The good news is that you don't need to: we already make nightly backups of all MySQL databases.

(That said, note that the MySQL backups just save a copy of your data on our servers. It's wise to also copy those backup files to your own computer, but you can't usually automate that with cron jobs on our servers — you'd need the equivalent of a cron job on your own computer.)