Scheduled tasks

A scheduled task is a command the server runs for you at fixed times, whether or not anybody is signed in. A cleanup script at three in the morning, an import every ten minutes, a newsletter on the first of the month: those are all scheduled tasks. If you have used another panel, or crontab -e, you know them as cron jobs — same thing, with a screen in front of it.

You will find them under Accounts → your account → Scheduled tasks. If that tab is not there, your package does not include them; your hosting provider can add it.

What your command gets

This is the part that costs the most time when you do not know it, so it is at the bottom of the page rather than only in this document. A scheduled task runs as your account, in your own environment:

Three things worth remembering:

1. Your task does not start in the same environment as your shell. What you put in your .bashrc does not apply here. So use whole paths: not php script.php but /usr/bin/php /home/you/script.php.
2. Your task sees your own files and nobody else's. The server puts every scheduled task in the same separation an SSH session gets: your own home, your own processes, nothing of the neighbours'. A script that looks in /home/somebody-else finds nothing — that is not a fault.
3. Your temporary files are yours. TMPDIR points at a folder of your own, so they count against your disk space and nobody else can read them.

Scheduling a task

Press New task. A panel slides open with, top to bottom, the questions in the order you answer them.

Kind of task. Three of them:

• Command — a command as you would type it in a shell.
• Fetch a URL — the server fetches an address. Useful for scripts that really start from the website; the server uses curl for it.
• PHP script — a PHP file. You pick which website runs it, and it then runs with that website's PHP version. That is why the question is asked at all: a script running on a newer PHP than the site it belongs to works here and breaks on the website.

When. Three ways of saying the same thing, and you may mix them:

• the preset at the top ("every quarter of an hour", "every night at 3");
• the five fields below it — minute, hour, day of month, month, day of week;
• the cron expression itself, which stays visible and which you can simply type.

Whichever you use, the expression underneath is what the server reads. It is deliberately always there: it is the one line you can check before scheduling something for three in the morning every night.

Mail the output. What happens to whatever your command prints:

This is set per task rather than once for your whole account: an import that runs every ten minutes is not something you want in your mailbox every ten minutes, and a monthly invoice run is. Leave the address empty and it goes to your account itself.

Description. Optional, but write one. In a year /usr/bin/find /home/you/tmp -mtime +7 -delete will tell you nothing, and "clean up old temporary files" will.

Run it once first

At the bottom of the panel there is Run now. That button runs your command straight away — exactly the way the schedule will, with the same PATH, in the same separation — and shows you what comes out and which code it stopped with. The schedule itself does not change, and you can use it before you save anything.

It is the quickest way to find out that you forgot a path. A task you schedule without testing is a task you find out about the next morning — or never, if you switched the mail off.

A test run stops after thirty seconds. A real, scheduled run does get all the time it needs; those thirty seconds exist only because you are standing in front of a screen waiting.

Switching on, switching off, deleting

A task you switch off stays in the list and stops running. That is not the same as deleting it: you can still see what it said and you can switch it back on later. Deleting really removes it; whatever the task has already done stays as it is, of course.

Warnings you may meet

"This runs every 2 minutes." Under five minutes a run can start before the last one has finished, and then they pile up until the server cannot keep up. It is allowed — a queue that looks every minute is a perfectly normal thing to want — but make sure your script cannot run twice over itself.

"Not set up in the panel." Lines you added yourself over SSH with crontab -e keep running and are only shown here. The panel does not touch them, because that would overwrite your work. To change such a line, use SSH.

Your package is full. If your hosting package sets a maximum number of tasks, the New task button is disabled once you reach it, with the number on it. Jobs you scheduled over SSH yourself do not count towards it.

On the command line

With SSH access you can do the same from the server:

$ corectl cron list --account youraccount
ID            ON   SCHEDULE        NEXT              WHAT
c5496f97009b  yes  */10 * * * *    27-08 06:10       */10 * * * * /usr/bin/php …

every job runs with PATH=/usr/local/bin:/usr/bin:/bin and TMPDIR=/home/youraccount/tmp, in Europe/Amsterdam

$ corectl cron add --account youraccount --schedule "17 3 * * *" \
    --command "/usr/bin/find /home/youraccount/tmp -mtime +7 -delete" \
    --description "clean up old temporary files" --mail errors

$ corectl cron run --account youraccount --command "id -un; echo \$TMPDIR"

And your ordinary crontab -l keeps doing what it always did: the panel's own lines are at the bottom of it, each with a #corecp line above it that is how the panel recognises them.

See also

• Files, FTP and SSH — where your scripts live and how to get them there.
• The web terminal — a shell in the panel, with the same separation your scheduled tasks get.
• PHP settings — which PHP version a website runs, and therefore which one your PHP task gets.