Plesk's Scheduled Tasks is a friendly front end for cron: pick what to run, when, and whether to email you the output. It runs the task as the subscription's user, which avoids the ownership problems of hand-written root crontabs. Here is how to set one up and how to fix the ones that do not run.
Create a task
- Websites & Domains → Scheduled Tasks (in the domain's tool list or the left menu).
- Add Task.
- Task type — three kinds:
- Run a command — any shell command, e.g.
/usr/local/bin/backup.sh. - Fetch a URL — Plesk requests the URL on schedule. Ideal for WordPress cron, Laravel's scheduler over HTTP, or any script that expects to be called as a web request.
- Run a PHP script — pick a file under the site and the PHP version to run it with. The right choice for
artisan schedule:run,wp cron event run, or a custom script.
- Run a command — any shell command, e.g.
- Run — presets (hourly, daily, weekly, monthly) or Cron style with a full expression. Explanations of the syntax are in scheduling tasks with cron.
- Description — say what it is; future you will thank you.
- Notify — Errors only to your email. Plesk considers a non-zero exit code or output on stderr an error.
- OK, then Run Now to test.
Common tasks
WordPress cron, reliably. WP-Cron runs when a visitor loads a page, which is unreliable on a quiet site and wasteful on a busy one. Disable it in wp-config.php:
define('DISABLE_WP_CRON', true);Then a Run a PHP script task every 5 minutes, or Fetch a URL of https://example.com/wp-cron.php?doing_wp_cron. WordPress Toolkit also offers this as a toggle.
Laravel scheduler:
- Type: Run a command
- Command:
cd /var/www/vhosts/example.com/httpdocs && /opt/plesk/php/8.3/bin/php artisan schedule:run - Every minute:
* * * * *
Database dump nightly:
mysqldump --single-transaction -u user -p'pass' dbname | gzip > /var/www/vhosts/example.com/private/db-$(date +\%F).sql.gzNote \%F — cron treats an unescaped % as a newline. (Storing dumps under private/, not httpdocs/, keeps them off the web.)
Clearing a cache directory weekly:
find /var/www/vhosts/example.com/httpdocs/wp-content/cache -type f -mtime +7 -deleteWhy a task "does not run"
Wrong PHP path. Plain php in a command may not exist or may be an old version. Use the full path: /opt/plesk/php/8.3/bin/php. The PHP-script task type handles this for you.
Relative paths. The task runs from the user's home, not the site. cd first, or use absolute paths everywhere.
Permissions. The task runs as the subscription user; a script owned by root or with no execute bit fails silently. chmod u+x script.sh, owner the subscription user.
Shell access disabled. Under Web Hosting Access, the system user's shell must be /bin/bash (or at least not Forbidden) for command tasks to run. Fetch-URL and PHP-script tasks work regardless.
Output but no error. Plesk emails only on errors; if you want the output every time, choose Notify: Every time, or redirect it to a log file in the command.
It runs, but too often. A task that takes longer than its interval overlaps itself. Wrap the command in flock -n /tmp/task.lock to skip a run while the previous one is still going.
Seeing what happened
Each task's row shows the last run time and status. The output of the last run is in the email if notifications are on; otherwise add >> /var/www/vhosts/example.com/logs/cron.log 2>&1 to the command and read that file under Logs.
Server-wide tasks
Tasks for the server rather than a site — a system backup, a cleanup — go under Tools & Settings → Scheduled Tasks and can run as root. Use that sparingly; a task that touches one site should run as that site's user.
On VPSPioneer shared plans, Scheduled Tasks is available on every subscription with shell access enabled by default; on a managed VPS tell us the job and the schedule and we set it up with failure alerts wired to our monitoring.