Create and run cron jobs in cPanel

A cron job runs a command at the frequency you set. Use it to schedule actions such as processing a queue, generating a report or running an application's maintenance.

Although you can manage them from the terminal (the crontab command), the Cron Jobs section of cPanel makes setting them up easy through a simple interface.

Email for notifications

This is the address cron sends the command's standard output and errors to. If the job produces no output, you will not get a message confirming each run.

Add new jobs

In cPanel > Cron Jobs, use Add New Cron Job. Choose a common frequency or fill in minute, hour, day of month, month and weekday. Then enter the command and save.

In the command, set what you want to run. For example, if you have a cron.php file in public_html that performs maintenance tasks, enter:

cd /home/usuario_cpanel/public_html && /opt/alt/php83/usr/bin/php cron.php >> /home/usuario_cpanel/cron.php.log 2>&1

The example uses PHP 8.3: check that this version exists and is compatible. Always use the full PHP path for your application: /usr/local/bin/php or plain php may be a different version, with different extensions. cd sets the working directory for scripts that use relative paths; && stops them running from another folder if the change fails. The example saves the output to a log so you do not lose errors. Review and rotate that file: sending everything to /dev/null avoids the emails, but it also hides any failure of the job.

Call a URL from cron

When an application provides a task URL, you can request it with curl:

curl --fail --silent --show-error --max-time 300 https://tudominio.com/ruta-de-cron

During the first tests, keep the diagnostic output and check the result of the job in the application. The email contains the output, not necessarily the exit code. Once you have confirmed it works, you can save it to a private log. Create the destination folder first with the right permissions:

curl --fail --silent --show-error --max-time 300 https://tudominio.com/ruta-de-cron >> /home/usuario_cpanel/logs/cron-url.log 2>&1

It is better to run the application's PHP or CLI command directly when there is one, because it avoids DNS, SSL and a full web request. Do not include passwords or permanent tokens in a URL that may end up stored in histories and logs.

Choose an interval longer than the maximum run time. If a call takes five minutes and you schedule another every minute, the jobs can overlap and exhaust processes. The application itself must implement a lock when it does not support simultaneous runs.

Current cron jobs

Current Cron Jobs lists the cron jobs you have added so you can edit or delete them as needed.

Check the schedule

These times follow the server's cron environment; confirm its time zone before scheduling an action tied to a local time. In cPanel, fill in those fields separately: do not add the five fields to the Command box.

After saving, check the next run through its log or the expected result. A successful manual test does not prove that cron has the same environment: it does not usually load .bashrc, your terminal's variables or NVM. Use absolute paths and explicitly configure whatever the script needs.

Avoid simultaneous runs

If the command runs in the foreground and flock is available, you can hold a lock for its whole run:

/usr/bin/flock -n /home/usuario_cpanel/tarea.lock /opt/alt/php83/usr/bin/php /home/usuario_cpanel/apps/mi-proyecto/tarea.php

Check the paths and that the application does not depend on another working directory. The lock is released when the command finishes; it does not cover jobs it launches in the background or remote processes that carry on after an HTTP call. If it cannot get the lock, -n skips that run: check that this behaviour suits your job.

Deleting a cron entry prevents future runs, but it does not stop one that is already running. If the job takes payments, sends messages or changes data, check its status before repeating it after a timeout.

Queue workers: cron or persistent processes

A queue worker launched from cron has to finish when there is no work left and must not overlap with the next minute's. For example, for Laravel, every minute:

cd /home/usuario_cpanel/apps/mi-proyecto && /usr/bin/flock -n /home/usuario_cpanel/.cola-mi-proyecto.lock /opt/alt/php84/usr/bin/php artisan queue:work --stop-when-empty --max-time=300

It processes what is pending and exits; if the previous one is still working, flock -n skips that run. Jobs wait one minute at most. In Laravel you can also launch it from the scheduler, as we explain in Install Laravel.

Do not use cron to leave a worker running with & or nohup: nothing watches it, so if it dies it does not come back, and without a lock another one is added every minute.

On the Avanza, Max and Elástico plans, persistent processes keep a queue worker, Horizon or your own command running at all times, and restart it if it dies. If you use them, you will see a line in your cron jobs ending in # hostsuar-procesos: it is the watchdog that checks them every minute. Do not edit or delete it; it is managed from Tools > Processes.

A line with schedule:run ending in # hostsuar-deploy- and a number is the scheduler of a Laravel application that Deploy+ set up when publishing it. That one is yours: you can change or delete it like any other.