Scheduled tasks on a website
Scheduled tasks run a PHP file from your own website on a timetable, as that website's own Unix account. This is where they live, what they can reach, and how to read what the last run printed.
Where they are
Under the website, not the server.
Open a website and choose Scheduled tasks. Everything is per website, because a task is a PHP file belonging to that website and runs as its Unix account — the same identity that serves its pages. Nothing you schedule here can read another website's files.
Scheduled tasks need a PHP runtime. A static website has no PHP to run, so the section tells you so rather than offering a timetable that could never fire. Change the runtime first if the site is static.
The timetable
Five cron fields, in the order cron uses them.
A task is a file to run and when to run it. The cron fields are the ordinary five — minute, hour, day of month, month, day of week — so a timetable you already know from a crontab means the same thing here. The panel writes the crontab entry for the website's account; you do not edit a crontab by hand and you do not need shell access to make one.
Pick the file with the file picker rather than typing a path. The file has to be inside the website, and scheduled tasks are refused a path outside it, for the same reason the SFTP account is locked to the same directory.
What it printed
Task output, for the run that just happened.
Each task keeps what its last run wrote, and Task output shows it. That is usually the whole of debugging a schedule: a task that appears not to run has often run and failed on its first line, and the output says which line. A task that has never run yet says that instead of showing an empty box, so you can tell "nothing yet" from "nothing printed".
Mail is not how you find out. Ordinary cron emails the account, and an account that cannot receive mail loses the message; the panel keeps the output where you can read it instead.
What a task may do
PHP, and only PHP.
A scheduled task runs a PHP file. It does not run a shell command, and PHP itself cannot run a command on these servers — the runtime is built without the functions that would start one. That is deliberate: a website that is broken into should not be a way to run programs on the machine, and a schedule is exactly the thing an attacker would reach for to keep a foothold.
So a task is the right tool for work your application already knows how to do — sending a digest, pruning a table, rebuilding a cache, calling an API — and the wrong tool for driving system utilities. If you need the latter, it belongs on the server rather than inside a hosted website.
Two things worth knowing
Limits apply, and so does the clock.
A scheduled task runs under the same PHP limits as the website's pages, including its memory limit, so a task that needs more memory than a page needs the limit raised for the website. See the guide on PHP versions, settings and extensions.
Times are the server's. If your business runs to a different timezone, write the schedule in the server's time rather than assuming yours, and check the first Task output to confirm it fired when you meant.