A scheduled task runs a command, PHP script or supported URL action at an agreed time. It is useful for application maintenance and background processing, but a duplicate or incorrectly scoped task can send repeated messages, consume resources or change production data.
IN THIS ARTICLE
Check access and requirements
Obtain the exact task from the application documentation, including its runtime, arguments and schedule. Confirm the subscription user and server timezone. Plesk on Linux commonly runs customer commands in a restricted shell environment, so a path that works in an administrator session may not work for the task.
01 Create a scheduled task in Plesk
- Open the subscription Scheduled Tasks page and choose Add Task.
- Choose the task type. For a PHP script, select an available PHP version compatible with the application and use the script path expected by the form. For a command, include required paths and arguments.
- Choose the execution schedule and review its timezone. Avoid scheduling multiple heavy jobs at the same minute. Add a description identifying the application and purpose.
- Configure a monitored notification address and appropriate error reporting. Ensure task output will not disclose passwords or confidential records in email.
- Save the task. Use Run Now only when it is safe to execute the real operation immediately; it is not a syntax-only test. Check whether the application already runs the same job through another scheduler.
02 Example: test a PHP task without changing application data
If your subscription offers Run a PHP script, create a private file named task-check.php within the subscription but outside the public document root:
<?php
echo "Scheduled PHP test completed", PHP_EOL;
Create a separate diagnostic task, choose the required installed PHP version, and select that file using the script picker. Plesk expects the script path relative to the virtual host directory; use the path the picker supplies. Run it once and look for Scheduled PHP test completed in the result. It reads no application records and sends no business messages.
A successful probe confirms this selected runtime and path can execute; it does not prove the application job works. Remove the diagnostic task and file after testing, then validate the real job through its normal documented schedule.
How do I test the scheduled task?
Confirm one expected run in the task result and application log. Verify the business outcome, such as a processed queue or refreshed data, instead of relying only on an email being delivered.
Resolve setup problems
For a command-not-found or file error, check the restricted environment, path and runtime. For overlapping jobs, use application-supported locking and a realistic interval. Disable a harmful task first, preserve its settings and investigate; do not repeatedly run it against production to guess the correct command.