How to Create a Cron Job in ISPConfig

This guide shows you how to create a cron job in the ISPConfig control panel, so that a command or a web address on your hosting account runs automatically on a schedule you choose. It is written for Noiz clients managing their own hosting account through ISPConfig. A cron job is sometimes called a scheduled task, a crontab entry or simply a "cron"; typical uses include running a maintenance script every night, triggering a WordPress or shop-system background task, or fetching a page every few minutes. The guide also explains the schedule syntax, the difference between command crons and URL crons, and where the output of your cron job is logged.

Last reviewed: 27 July 2026, against ISPConfig 3.3.1p1. This guide is written for Noiz hosting and is kept current against ISPConfig. It complements, and does not replace, the official ISPConfig documentation linked below. ISPConfig evolves between releases, so if a screen differs from this guide, check those links.

Official Documentation Reference

• ISPConfig Documentation overview: the index of all official ISPConfig documentation, including the full manual whose chapter 4.6.4.2 covers cron jobs.
• ISPConfig 3.3.1p1 cron job form (official source repository): the exact form definition this article was checked against, including the field hints and placeholder variables.
• Cron Jobs and how to use them: an introduction (HowtoForge): the general cron scheduling tutorial that the official ISPConfig manual itself refers readers to.

Prerequisites

• You can log in to the ISPConfig control panel.
• At least one active website exists on your account, because every cron job belongs to a website. If you have none yet, first create a website in ISPConfig.
• You know what you want to run: either the full path to a script on your hosting account, or a web address such as https://yourdomain.com/cron.php (an example placeholder; use your own domain).
• Your hosting plan includes cron jobs. The number of cron jobs, the allowed cron types and the minimum interval between runs are set per account, so if the Cron Jobs menu item is missing, your plan may not include them.

Open the Cron Job Form

1. Log in to the ISPConfig control panel.
2. Click the Sites module in the top navigation.
3. In the left menu, under Command Line, click Cron Jobs. A list of any existing cron jobs on your account appears.
4. Click the Add new Cron job button.

The Cron Job form opens. It contains the website selector, five schedule fields, the command field, and the Log output and Active options, all on a single tab.

Choose the Parent Website

In the Parent website drop-down, select the website this cron job belongs to. This choice matters for two reasons:

• The job runs as that website's own system user, so it has exactly the same file permissions as the website itself. It can read and write the site's files but nothing belonging to other sites.
• Any log files the job produces are written into that website's private folder (explained below).

Set the Schedule

The next five fields define when the job runs. Each field accepts *, a number, a list, a range or a step value, and ISPConfig shows a short example hint next to each one.

• Minutes: the minute of the hour to run the job. Allowed values 0 to 59; * means every minute.
• Hours: the hour of the day. Allowed values 0 to 23; * means every hour.
• Days of month: the calendar day. Allowed values 1 to 31; * means every day of the month.
• Months: the month. Allowed values 1 to 12; * means every month.
• Days of week: the weekday. Allowed values 0 to 7, where both 0 and 7 mean Sunday; * means every day of the week.

Schedule Syntax

Within each field you can combine values in the standard cron ways:

• * matches every possible value of the field.
• A list such as 1,2,5,9 matches each listed value.
• A range such as 0-4 matches every value from 0 to 4, and you can combine ranges with lists, for example 0-4,8-12. The second number must be higher than the first, so 5-1 and 5-5 are both rejected.
• A step such as */5 means every fifth value, so */5 in Minutes runs the job every five minutes. Steps also work on ranges: 1-9/2 is the same as 1,3,5,7,9. The step must be 2 or higher, so */1 is rejected; write * instead.
• Only digits and the characters *, ,, - and / are accepted. General cron documentation allows three-letter names such as jan or sun, but ISPConfig refuses them with an "Invalid format" message, so always use numbers.
• Of the special @ keywords found in general cron documentation, ISPConfig accepts only @reboot, and only in the Months field. Entered there it runs the job once each time the server starts. The other four fields still need a valid entry such as *, but they are ignored.

One rule often catches people out: if you restrict both Days of month and Days of week (that is, neither is *), the job runs when either field matches, not both. For example, minutes 30, hours 4, days of month 1,15, days of week 5 runs at 04:30 on the 1st and 15th of every month and on every Friday.

Common Schedule Examples

• Every 5 minutes: Minutes */5, all other fields *.
• Every hour, on the hour: Minutes 0, all other fields *.
• Every night at 02:30: Minutes 30, Hours 2, remaining fields *.
• Every Sunday at 06:00: Minutes 0, Hours 6, Days of week 0, remaining fields *.
• First day of each month at midnight: Minutes 0, Hours 0, Days of month 1, remaining fields *.

Note that your account may enforce a minimum interval between runs. If your plan's minimum is five minutes, for example, ISPConfig will refuse a schedule that fires every minute.

Enter the Command or URL

The field labelled Command to run (commands are executed via sh, urls via wget) takes either a shell command or a web address. Which of the two you use changes how the job behaves, so pick deliberately. The field holds at most 255 characters, so put anything longer into a script and call the script instead.

Command Crons

If you enter a shell command, it is executed by sh under your website's system user. Always use full absolute paths, because cron jobs do not start in your website folder and have only a minimal environment. A typical example that runs a PHP script inside your web space looks like this:

{SITE_PHP} {DOCROOT_CLIENT}/scripts/maintenance.php

The curly-bracket tokens are placeholders that ISPConfig fills in for you when the job runs. The Variables row just below the field lists the ones available; hovering over one shows the actual value for the selected website, and clicking it inserts the placeholder into the command:

• {SITE_PHP}: the PHP command-line binary matching the PHP version selected for the website, so your cron runs the same PHP version as the site itself.
• {DOCROOT_CLIENT}: the full path to the website's web folder, the same folder your site files live in.
• {DOMAIN}: the website's domain name.

Using the placeholders is strongly recommended over typing server paths by hand: they always resolve to the correct location for your account, and they keep working if the site is ever moved.

On some accounts, command crons run inside a restricted (Jailkit) environment for security, shown by a padlock icon beside the Parent website drop-down whose tooltip reads Jailkit secured cronjob. In that case only files inside your own site directory are reachable, and system-wide tools may not be available; scripts within your web space work as normal.

URL Crons

If you enter a web address starting with http:// or https://, ISPConfig does not run a shell command at all. Instead it fetches the address with wget at each scheduled time, which makes the web server execute the page exactly as if a visitor had opened it. For example:

https://yourdomain.com/cron.php

Points to know about URL crons:

• Only http and https addresses are accepted; anything else is rejected as an invalid command.
• Some accounts are limited to URL crons only. On those accounts the address must start with https://, and anything else is refused with URL cron only. Please enter a URL starting with https:// as cron command.
• The {DOMAIN} placeholder works here as well, so https://{DOMAIN}/cron.php keeps pointing at the right site. {SITE_PHP} and {DOCROOT_CLIENT} apply to command crons only.
• The address is fetched once per scheduled run, with a single attempt and a generous timeout of two hours, so long-running scripts are not cut off prematurely.
• The page must be reachable from the internet without logging in. If the script should not be run by strangers, protect it with a secret token in the address rather than a login page, for example https://yourdomain.com/cron.php?key=example-secret.

URL crons are the right choice for application background tasks (WordPress, shop systems, newsletter tools) that ship a "cron URL". Command crons are the right choice when you need to run a script directly with PHP or shell access to your files.

Logging, Activation and Saving

1. Tick Log output if you want ISPConfig to record what the job produces. Logging is the easiest way to confirm a new job actually works, so enabling it on a new cron job is good practice.
2. Leave Active ticked so the job starts running. Unticking it keeps the job saved but switched off.
3. Click Save.

ISPConfig applies the change to the server automatically; allow a minute or so before the first run can happen. The job then runs on your schedule with no further action needed.

Where the Logs Go

With Log output enabled, log files are written into the private folder of the parent website, alongside your web folder. You can view them with your FTP account for that site:

• private/cron.log: the normal output of your command.
• private/cron_error.log: error output, the first place to look when a job misbehaves.
• private/cron_wget.log: for URL crons, the content of the page that was fetched.

These files sit outside the web folder on purpose, so visitors to your website can never download them. Log files grow with every run, so check and clear them occasionally if your job runs frequently.

Safety Notes

• Test the command first. Run the script by hand, or open the URL in a browser, before scheduling it. A cron job repeats whatever it does, including mistakes.
• Be conservative with frequency. A heavy script every minute can slow your whole site down. Schedule maintenance work during quiet hours, such as the early morning.
• Be careful with destructive commands. A cleanup script that deletes files runs unattended; double-check its paths so it can only ever touch what it should.
• Watch for overlap. If a run can take longer than the gap before the next run, the two can overlap. Lengthen the interval or make the script exit early if a previous run is still busy.
• Keep secrets out of logs. Anything your script prints ends up in cron.log; avoid printing passwords or API keys.
• Deactivate rather than delete. If you only need to pause a job, untick Active and save; the schedule and command stay intact for later.

Troubleshooting

Symptom: the Cron Jobs menu item is missing under Sites: your hosting plan does not currently include cron jobs, or the limit is set to zero. Open a support ticket to have it enabled.

Symptom: "The cron job frequency exceeds the allowed limit." when saving: your schedule fires more often than your account's minimum interval allows. Lengthen the interval, for example from every minute to every five minutes.

Symptom: "The maximum number of allowed cron jobs was reached.": delete a cron job you no longer need, or ask the Noiz support team about raising the limit on your plan.

Symptom: "Invalid command format. Please note that in case of an url call only http/https is allowed.": the command starts like a URL but is not a plain http:// or https:// address, or your account is URL-cron only and the entry is not a valid https:// address. Correct the address, or enter a proper shell command instead.

Symptom: the job saves but never seems to run: check that Active is ticked, wait a couple of minutes after saving for the server to pick up the change, then enable Log output and check private/cron.log and private/cron_error.log after the next scheduled time. For command crons, confirm every path in the command is absolute and correct.

Symptom: the job runs but the log files are empty: an empty cron.log usually just means the script produced no output, which is normal for many well-behaved scripts. Add a line to your script that prints a timestamp if you want positive confirmation of each run.

Symptom: a URL cron runs but the task is not done: open the URL in a private browser window. If it needs a login, redirects, or shows an error page, the scheduled fetch sees the same thing. Check private/cron_wget.log to see exactly what the fetch received, and adjust the script so it works without a logged-in session.

If you get stuck at any point, open a support ticket with the Noiz support team and include the domain of the parent website, the exact command or URL, the five schedule values, and the most recent lines of private/cron.log or private/cron_error.log if logging was enabled.