Crontab overview


The crontab command, found in Unix and Unix-like operating systems, is used to schedule commands to be executed periodically.

Generally, crontab uses a daemon, crond, which runs constantly in the background and checks once a minute to see if any of the scheduled jobs need to be executed. These jobs are generally referred to as cron jobs. Cron jobs run as the user who creates them, as though that user typed the command into their shell.

Only shell users can create cron jobs. For help setting up a shell user, see the Creating a user with Shell (SSH) access article.

Crontab file contents on the server

Due to the complex nature of translating user supplied content from the panel to the server, what you enter in to the panel is not what you see in the crontab file. The following example is a more complex cron job using a wget command.


The crontab file on the server then appears as follows:

###--- Changes made to this part of the file WILL be destroyed!
# testing a cron
@hourly /usr/local/bin/setlock -n /tmp/cronlock.3788814087.215158 sh -c $'/usr/local/php71/bin/php /home/example_username/mail.php'
###--- You can make changes below the next line and they will be preserved!

When the 'Use locking' option is selected, the command(s) you want executed are filtered through a unique invocation of the setlock command.

View the setlock man page for further information. The use of setlock results in error messages if your cron job is invoked before the last iteration of the job releases your unique lockfile. This can happen if your script takes more time to run than the time between job executions.


  • When testing your new cron job, set the 'When to run' time frame to run every 10 minutes. Also, make sure to set an email address for reporting the results. This gives you important information about what may be going wrong if the command line is not running the cron job as desired. When everything is running properly you can then adjust the 'When to run' value to anything you like.
  • If you're planning to use external software with a cron job, make sure you have set 'write' and other permissions for the files in your remote folders. If you get an error message about "permission denied" it means your permissions are not set properly. Also specifying the full path of the file you’re writing to can prevent issues with the cron environment running from a different directory.

Could not open input file

You may be emailed this when the cron job fails to run.

First, make sure the username you've assigned to run the command in your panel has access to the file. Also make sure the file permissions allow the user to run it.

If your permissions are correct, check the subject of the email that was sent to you. It will start like this:

Cron <username@server>

Make a note of this 'username', then check the Cron Job you created in the panel. These should be the same username. If the username is different than what you see in the panel, contact support. They will be able to run a configuration on the old username to fix this.

Dedicated server troubleshooting

It's rare that the cron service on a server may stop running. If you’re using a Dedicated server, you can verify that cron is running by running this shell command:

[server]$ ps aux | grep cron

You can also check the system log for entries labeled 'CRON'.

[server]$ sudo grep CRON /var/log/syslog

There is usually at least one CRON line per minute in the /var/log/syslog file. If you don’t see any recent entries then you may want to restart the cron service. To restart cron run this command under your Dedicated server's admin user:

[server]$ sudo service cron restart

See also

Did this article answer your questions?

Article last updated PST.