With a Cron job you can have specific commands or scripts executed automatically on your web hosting at scheduled times. For example, cron jobs are suitable for regular maintenance tasks, imports, exports, data processing, or time-controlled PHP scripts.
In CURIAWEB-cPanel, you can create and manage cron jobs directly through the user interface. Two details are particularly crucial: When should the cron job be executed and which command should be run?
In this guide, we will show you how to create a cron job in cPanel, set time intervals correctly, use absolute paths, and avoid common mistakes.
Important: A cron job executes the entered command automatically. Therefore, especially with scripts, imports, deletion, or maintenance functions, carefully check what the command does before letting it run regularly.
What is a cron job? #
A cron job is a time-based task on a Linux system.
Simply put, a cron job consists of:
Schedule
+
Command
=
automatically executed taskFor example, you can use this to define:
Every day at 03:00 AM
→ Run PHP scriptor:
Every 15 minutes
→ start specific processThe server will then automatically take over the execution, without you having to log in to cPanel every time.
What are cron jobs used for? #
Cron jobs are used by web applications and custom scripts for a wide variety of recurring tasks.
Typical examples are:
- regular data imports
- automatic exports
- Queue processing
- timed maintenance tasks
- Calling custom PHP scripts
- Data synchronization
- Execution of CMS or shop tasks
Which cron jobs are needed depends on the application being used.
Do not create a cron job without specifying an application #
If software documentation requires a specific cron job, you should use the command specified there and the recommended interval as a starting point.
Do not invent an execution command yourself if you do not know how the application processes its timed tasks.
Practical Tip: Many web applications already specify a complete cron command in their documentation, or at least the script to be executed and a recommended interval.
1. Log in to cPanel #
Log in to your CURIAWEB cPanel.
Then open:
Advanced Options → Cronjobs
There you can view existing cron jobs and create new tasks.
2. Check email address for cron job output #
In the cron job section, cPanel can offer a setting for email notifications or cron output.
If a cron job produces output, it can—depending on the configuration—be sent via email.
This can be very helpful during setup and troubleshooting.
Important: Do not suppress the output of a new cron job immediately. Especially during the first test, error messages can provide important clues if the command does not work correctly.
3. Add new cron job #
Go to the new cron job addition section.
A cron job fundamentally requires:
- Minute
- Hour
- Day of the month
- Month
- Day of the week
- Command
cPanel can additionally offer predefined schedules or general settings that make it easier to select frequently used intervals.
Understanding the five time fields #
The classical cron syntax consists of five time fields:
Minute Hour Day Month WeekdayThe command to be executed follows.
The simplified schema looks like this:
* * * * * Command
│ │ │ │ │
│ │ │ │ └─ Day of the week
│ │ │ └─── Month
│ │ └───── Day of the month
│ └─────── Hour
└───────── MinuteWhat does the asterisk * mean? #
One star:
*
in a cron time field generally means that every possible value of this field is taken into account.
For example:
* * * * *corresponds to a very common implementation – namely, basically every minute.
Attention: Use
* * * * *not without consideration. A script that is started every minute can consume unnecessary resources or run multiple times simultaneously if an execution takes longer.
4. Set schedule #
Now define how often the cron job should run.
If the application used specifies a certain interval, you should generally follow this recommendation.
Example: every 5 minutes #
A cron job every five minutes typically uses:
*/5 * * * *This means:
Minute: */5
Hour: *
Day: *
Month: *
Weekday: *The command will therefore generally be executed every five minutes.
Example: every 15 minutes #
*/15 * * * *This means execution generally occurs every 15 minutes.
Example: every hour #
Should the cron job be executed at the beginning of every hour:
0 * * * *For example:
01:00
02:00
03:00
04:00
...Example: daily at 03:00 AM #
0 3 * * *This means:
Minute: 0
Hour: 3
Day: *
Month: *
Weekday: *The cron job basically runs once a day at 03:00 AM according to the server time relevant for the cron execution.
Example: daily at 3:30 AM #
30 3 * * *The cron job will therefore generally be executed daily at 03:30 AM.
Example: every Monday at 06:00 AM #
0 6 * * 1Here is the 1 for Monday.
Example: on the first day of each month #
Should a cron job run on the first day of every month at 02:00 AM:
0 2 1 * *Example: every six hours #
One possible spelling is:
0 */6 * * *This means the command will generally be executed on a six-hour schedule.
Lists and ranges in cron expressions #
In addition to single values and asterisks, Cron also supports other notations.
A hyphen can define a range:
1-5A comma-separated list can specify multiple concrete values:
1,3,5A slash can be used for an interval:
*/10Which combination makes sense depends on the desired schedule.
Use predefined cPanel schedules #
For frequently needed intervals, you can use the general or predefined settings offered by cPanel.
This reduces the risk of accidentally setting the five time fields incorrectly.
Check the resulting values anyway to ensure they actually match the desired schedule.
Differentiate server time and local time #
An important point with cron jobs is the underlying time zone.
The server time decisive for the execution does not necessarily have to correspond to your local time.
Therefore, if a cron job needs to run at a specific local time, you should check which time zone applies to the cron execution.
Important: If a cron job seemingly runs one or more hours „too early“ or „too late,“ first check the timezone before changing the schedule on a hunch.
Account for daylight saving time and standard time #
Time changes can also play a role in time-critical tasks.
Whether and how a time change affects a cron job depends on the system's timezone configuration.
If a task must strictly run at a specific Swiss local time, you should check the actual execution times accordingly.
5. Enter the command to be executed #
In the field Command you enter what the server should execute at the specified time.
The specific command depends entirely on the respective application or task.
For a PHP script, the basic principle might look like this, for example:
/path/to/php-binary /home/CPANELUSER/public_html/script.phpThe actual paths must match your hosting account and the PHP environment used.
Attention: Do not copy PHP paths from third-party hosting tutorials. The path to the PHP binary can vary depending on the server, PHP environment, and PHP version.
What is a PHP binary? #
A PHP binary is the executable PHP program that can be used to start a PHP script via the command line.
During a web request, the web server or the configured PHP environment processes the PHP file. A cron job, on the other hand, requires a suitable executable PHP command for a direct CLI invocation.
Simplified:
Browser request:
Web server → PHP → Script
Cron job:
PHP binary → ScriptNote the PHP version of the cron job #
If your website uses a specific PHP version, you should make sure with a PHP cron job that the executed PHP command matches the application.
The PHP version of the website and the PHP version of a command-line call are not automatically the same.
Important: Executed via SSH
php -vor a general onePHP-command does not automatically prove that the exact same PHP version is also used for your website or your cron job.
You generally manage the PHP version of your domain at CURIAWEB via the MultiPHP Manager.
Use absolute paths #
For cron jobs, you should use absolute paths for scripts and files whenever possible.
An absolute path starts at the filesystem and uniquely identifies the destination.
For example, schematically:
/home/CPANELUSER/public_html/cron.phpA relative path like:
cron.phpis, however, dependent on the working directory from which the command is executed.
This can lead to unexpected errors during automatic cron executions.
Do not confuse web address and file system path #
A URL like:
is not the same as a file system path:
/home/CPANELUSER/public_html/cron.php
A URL refers to a resource via HTTP or HTTPS. A file system path refers to a file directly on the server.
Which variant an application requires depends on its documentation.
How do I find the correct file path? #
I'm cPanel File Manager Can you trace the directory structure of your hosting account.
For example, if your domain is assigned to a specific document root, the script to be executed is located within this directory structure.
Do not use automatically public_html, if the domain in question has a different document root.
Consider the Document Root of an additional domain #
With multiple domains, each website can be assigned to its own directory.
A cron job for:
shop.example.com
therefore does not necessarily point to a file under:
/public_html/
show.
Check the actual path of the application in question.
6. Add cronjob #
If the schedule and command are entered correctly, add the new cron job.
The cron job should then appear in the list of existing cron jobs.
Check there again:
- Minute
- Hour
- Day
- Month
- Day of the week
- Command
7. Test cronjob in a controlled manner first #
When setting up a new cron job, you shouldn't wait several days to see if the command actually works.
If the application allows, you can temporarily use a shorter interval for a controlled test.
Then you set the cron job back to the actual desired schedule.
Attention: Use a short test interval only if the running process can be safely started multiple times. An import, shipping process, or other modifying script must not be executed multiple times in an uncontrolled manner.
8. Check execution result #
How you determine whether the cron job was successful depends on the application being executed.
Possible control options are:
- Cron job output
- Email notification
- Application log file
- Timestamp of a generated file
- Status within the application
- processed datasets
An existing entry in cPanel only proves that the cron job has been set up – not that the executed command is working successfully.
Understanding the output of a cron job #
A command can generate normal output and error messages.
Under Linux, these are fundamentally treated as different output channels:
stdout
→ standard output
stderr
→ error messagesThis distinction becomes important when output is to be redirected or logged.
Write output to a log file #
For certain custom scripts, it can be useful to redirect the output to a file.
A schematic example:
COMMAND >> /home/CPANELUSER/logs/cron.log 2>&1This means:
>>
→ Append output to a file
2>&1
→ Redirect error output to standard outputUse only paths that exist in your hosting account and are writable.
Log files can get very large #
If a frequently executed cron job logs multiple lines every time it runs, a log file can grow considerably over time.
Therefore, regularly check custom-created cron logs or use suitable log rotation if this is intended for your application.
Suppress output with /dev/null #
In many cron tutorials, you will find constructions like:
COMMAND > /dev/null 2>&1/dev/null discards the output redirected there.
This can make sense with a reliably functioning cron job if you intentionally do not need the output.
Attention: Use
/dev/nullnot reflexively with a new or faulty cron job. You might discard the exact error message you need for the diagnosis.
Difference between > and >> #
When redirecting to files, the difference is important.
> writes the output to a file and completely replaces the previous content in the process.
>> always appends the new edition to the existing file.
Example:
COMMAND > cron.log
→ Rewrite file
COMMAND >> cron.log
→ Append outputWhat does 2>&1 mean? #
The spelling:
2>&1
directs the error output to use the same destination as the standard output.
This allows normal messages and error messages to end up together in a log file or be discarded together.
HTTP call via a cron job #
Some applications do not specify a direct PHP CLI command, but instead expect a URL to be called regularly.
Depending on the hosting environment and application requirements, a command-line tool for fetching an HTTP/HTTPS address can be used for this purpose, for example.
In this case, use the command recommended by the application.
Important: Do not replace a CLI call intended by the application with an HTTP call without reason, or vice versa. Both variants can behave differently from a technical perspective.
Distinguish between CLI call and HTTP call #
During a direct PHP CLI call, the PHP script is executed via the command line.
In contrast, an HTTP call accesses a web address, similar to how a browser or other HTTP client does.
Simplified:
CLI:
Cron → PHP → File
HTTP:
Cron → HTTP/HTTPS → Web server → ApplicationThe application determines which variant is intended.
Environment variables of a cron job can be different #
A cron job does not necessarily run with the exact same environment as an interactive SSH session.
In particular, search paths and other environment variables can differ.
This is why a command can work in an interactive shell while the same shortened command fails as a cron job.
Absolute paths to programs and files reduce such dependencies.
Cron job needs write permissions #
If a script is supposed to create, modify, or delete files, the executed process requires the corresponding permissions.
Therefore, a writing error does not automatically mean that the cron schedule is wrong.
Check for such problems:
- File path
- Directory
- File permissions
- application logic
You can find the basics of file permissions at How to correctly set file permissions 644 and 755 in cPanel.
Cron jobs and PHP limits #
A PHP script executed via a cron job can be subject to different conditions than a normal website request.
If a cron job fails due to memory requirements or execution time, the first thing to check is which PHP environment actually executes the command.
We cover the general PHP limits of a website under Set PHP memory limit, upload size, and execution time.
Important: Do not automatically transfer values from the web PHP configuration to PHP CLI. The deciding factor is the PHP environment that actually executes the cron command.
Cronjobs and PHP extensions #
Required PHP extensions can also play a role in a PHP script.
If a script works via the website, but reports a missing PHP function when run via a cron job, you should check whether the cron job is actually using the same or a compatible PHP environment.
You can find more information at Enabling and Managing PHP Extensions in cPanel.
Distinguish between WordPress WP-Cron and server cron #
WordPress features WP-Cron a custom system for scheduled tasks.
However, WP-Cron is not a classic Linux cron job.
By default, WordPress checks scheduled tasks in the context of website visits.
Simplified:
Visitor visits WordPress
→ WordPress checks scheduled tasks
→ due WP-Cron events can be processedA real server cron job, on the other hand, is started by the server schedule independently of a normal visitor request.
Why WP-Cron does not need to be accurate to the minute #
If a WordPress website receives few or irregular visits, scheduled WP-Cron tasks can be triggered later than expected.
WP-Cron is therefore not to be equated with a classic system cron that runs on a fixed schedule.
Trigger WP-Cron with a real cron job #
With certain WordPress configurations, it can be useful to trigger the processing of scheduled WordPress tasks regularly via a real server cron job.
However, this should be set up consciously.
If the normal WordPress WP-Cron mechanism is disabled, it must be ensured that the scheduled tasks are subsequently triggered reliably via the alternative mechanism.
Attention: Don't just disable WP-Cron in
wp-config.php, without having set up and tested a working replacement beforehand. Otherwise, scheduled WordPress tasks may fail to run.
Understand DISABLE_WP_CRON #
In WordPress, the normal calling mechanism of WP-Cron can be controlled via a constant in the file wp-config.php to be influenced.
A corresponding configuration may include, for example:
define( 'DISABLE_WP_CRON', true );This should only be used if an alternative and working mechanism for WordPress cron processing is deliberately set up.
The modification of the file wp-config.php should be backed up in advance and carried out carefully.
WooCommerce and Cronjobs #
WooCommerce and WooCommerce extensions use scheduled or background tasks for various processes.
Depending on the configuration, this may include, for example, scheduled actions, notifications, synchronizations, or other background processes.
Therefore, do not change the cron configuration of a production WooCommerce store without careful consideration.
Choose the frequency to match the task #
A cron job should not be executed more frequently than technically necessary.
If a task is only needed once a day, there is usually no reason to start it every minute.
An unnecessarily high frequency can:
- require additional CPU time
- Generate PHP processes
- trigger database queries
- load external APIs
- lead to overlapping statements
Avoid overlapping cron jobs #
A particularly important case arises when a cron job is started more frequently than its execution takes.
Example:
Cron job starts every 5 minutes
Execution takes 8 minutesThen the next execution can begin, even though the previous one has not yet finished.
Depending on the application, this can cause multiple identical processes to run simultaneously.
Attention: During long imports, synchronizations, or compute-intensive tasks, you should ensure that the selected interval matches the actual runtime or that the application prevents parallel executions.
Cron jobs and CloudLinux resources #
A cron job also consumes hosting resources.
For example, a frequently executed or compute-intensive script can consume CPU, memory, processes, or database resources.
If a cron job regularly coincides with a high load, its execution time and frequency should be reviewed.
We cover the resource evaluation under Understanding CloudLinux Resource Usage in cPanel.
Stagger multiple heavy cron jobs so they do not start in the same minute #
When running multiple resource-intensive tasks, it can make sense to stagger their start times.
Instead of, for example, three extensive processes all around:
03:00
To get started, different start times can be used, provided the applications allow it.
This prevents multiple peak loads from occurring unnecessarily at the same time.
Test cron job manually #
If you have SSH and know the command used for sure, a manual test can be helpful.
This makes it possible to distinguish whether:
- the command itself is faulty
- or only the automatic cron execution causes problems
However, a manual test should only be performed if the task in question can be safely re-executed.
Manual test works, cron job does not #
If a command works manually but not as a cron job, you should specifically check:
- absolute paths
- PHP-Binary
- Environment variables
- Permissions
- Cron schedule
- Outputs and error messages
We discuss systematic troubleshooting in the article Cron job not working: Causes and solutions.
Cron job doesn't seem to be running #
If a task is not executed at the expected time, check the schedule first.
A common mistake is confusing:
- Minute and hour
- Day of the month and day of the week
- local time and server time
- interval and specific time
Check the command itself afterwards.
Cronjob is running, but script produces errors #
In this case, the timed execution might work while the actual script fails.
Those are two different levels:
Cron starts command
→ works
Script is executed
→ produces errorsThen investigate the script's error message or its own log files.
Log PHP errors #
When a PHP script generates an error, depending on the configuration, appropriate logging can be helpful.
For website errors, we explain the cPanel logs under Read cPanel Error Log and find website errors.
Please note, however, that a CLI cron job does not necessarily use the same logs and PHP configuration as a normal web request.
Edit cron job #
Existing cron jobs are listed in the cPanel cron job section.
If you want to change a schedule or command, check the previous entry before making the change.
For more complex commands, it may be useful to copy or document the old value beforehand.
Delete cronjob #
If a cron job is no longer needed, you can remove it using the corresponding function.
Check before deleting whether the associated application still needs the cron job.
Attention: Deleting a cron job does not automatically delete the associated application. However, it can cause its scheduled background tasks to no longer run.
Check old cron jobs after website migration #
After a migration or a redesign of your hosting account, you should check existing cron jobs.
Absolute paths can change when moved.
For example, an old command might still point to a directory that does not exist on the new hosting.
Check cron jobs after PHP switch #
When an application is switched to another PHP version, you should also consider PHP-based cron jobs.
A cron job with a hardcoded PHP binary path can still call a different PHP version than the website.
Therefore, check for relevant PHP changes to ensure that time-controlled PHP scripts continue to run with the intended environment.
Do not write sensitive data directly into cron commands #
Avoid entering passwords, API keys, or other sensitive credentials directly into a cron command whenever possible.
Such information should be securely configured according to the respective application.
Securing publicly accessible cron scripts #
When a cron job calls a URL accessible via the web, you should check whether this URL can also be triggered by any visitors.
For sensitive or resource-intensive tasks, an application can provide its own protective mechanisms for this.
Use the fuse protection recommended by the respective manufacturer.
Examples of common schedules #
| Desired version | Cron schedule |
|---|---|
| Every minute | * * * * * |
| Every 5 minutes | */5 * * * * |
| Every 15 minutes | */15 * * * * |
| At the beginning of each hour | 0 * * * * |
| Daily at 3:00 AM | 0 3 * * * |
| Daily at 3:30 AM | 30 3 * * * |
| Every Monday at 06:00 AM | 0 6 * * 1 |
| At 02:00 AM on the 1st of every month | 0 2 1 * * |
| Every 6 hours on the hour | 0 */6 * * * |
Pre-saving checklist for a cron job #
Check before adding:
- Is the correct script or command entered?
- Do you use absolute paths?
- Does the appropriate PHP environment get considered for PHP scripts?
- Is the interval really necessary?
- Can the task take longer than the interval?
- Has the relevant time zone been taken into account?
- Do you need the output for the initial tests?
- Can the task be executed safely multiple times?
Recommended workflow for a new cron job #
- Check the documentation of the application used.
- Note the required command and the recommended interval.
- Log in to cPanel.
- Open Advanced Options → Cronjobs.
- Check the setting for cron email outputs.
- Set the desired schedule.
- Check minute, hour, day, month, and day of the week.
- Consider the time zone applicable to the cron job.
- Enter the full command.
- Use absolute paths for files whenever possible.
- Check the PHP binary used in PHP scripts.
- Do not unnecessarily suppress error messages during the first test.
- Add the cron job.
- Check the saved entry.
- Check after the first execution whether the task was successfully completed.
- Restore a temporarily shortened test schedule back to the desired interval afterwards.
When should you contact CURIAWEB support? #
If a cron job does not work despite a correct schedule and you cannot determine the cause, document the existing entry as precisely as possible.
For an analysis, the following information is particularly helpful:
- affected domain or application
- complete cron command without confidential credentials
- set schedule
- expected execution time
- actually observed behavior
- PHP version used or PHP binary, if relevant
- complete error message
- whether the command works manually
- whether the cron job has worked before
Do not transmit passwords, API keys, or other confidential access credentials.
Summary #
With cron jobs, you can have commands and scripts executed automatically on your CURIAWEB web hosting according to a set schedule. You can find the management under Advanced Options → Cronjobs.
A cron job consists of five time fields for minute, hour, day, month, and day of the week, as well as the command to be executed. Frequently used schedules include, for example, */5 * * * * for every five minutes or 0 3 * * * for daily execution at 3:00 AM.
Use absolute file paths for scripts wherever possible, and keep in mind for PHP cron jobs that the PHP version of a command-line call is not necessarily identical to the PHP version of the website.
Do not prematurely suppress output and error messages of a new cron job with /dev/null. You are often the most important source of information during setup and troubleshooting.
Also, make sure not to run a cron job more frequently than necessary. If a task runs longer than its execution interval, multiple processes can be created simultaneously and unnecessarily consume hosting resources.
In WordPress, you should also distinguish between WordPress's built-in WP-Cron and a real server cron job. If WP-Cron is disabled, a working alternative execution mechanism must be in place.
The most important rule is: Check schedule, command, file path, and execution environment separately. A correctly saved cron job does not automatically mean that the called script will execute successfully.
