In this article10 sections
Many websites need work done on a timer: send a digest email, clear expired sessions, rebuild a sitemap, or call an endpoint that imports orders. On Windows hosting, Plesk’s Scheduled Tasks are the place to set these up, and they run whether or not a visitor is on the site. A task that fails silently is worse than none, because the job just stops. This guide shows how to create a scheduled task in Plesk, how to call a web endpoint or run a command, how to protect the endpoint so only the schedule can use it, and how to check that each run actually happened.
SiteHarbour’s Windows hosting plans include Plesk and server monitoring on every plan. The scheduled tasks below run on your own website’s subscription, using the commands the plan’s Windows Server 2022 includes.
Before you start
- A task you want to run, and how often. A nightly job and a job that runs every minute need different designs.
- A website in Plesk that already serves the application, as described in how to deploy ASP.NET Core on Plesk Windows hosting.
- A way to identify the job, such as a secret token, which you will set in Step 3.
Step 1: Choose between a URL and a command
There are two common designs. Calling a URL keeps the logic inside your application, where it can use the same code and configuration as the website. Running a command runs a program directly, such as a PowerShell script or a .NET console tool. For most web applications the URL call is simpler, because the code is already deployed and tested. Use a command when the job must run when the website is down, or when it needs more time than a web request allows.
Step 2: Create the task in Plesk
In Plesk, open Tools & Settings, then Scheduled Tasks. Select Add Task. Enter a name that says what the job does, such as nightly-order-import. Choose the schedule: a daily time, an interval, or a custom pattern. Choose the command type you picked in Step 1.
Expected: the task appears in the list with its next run time shown. Keep the names clear. A list of tasks called “task 1” and “task 2” is hard to fix at two in the morning.
Step 3: Protect the endpoint
Any URL that runs a job can be found and called by anyone. Give the endpoint a secret token that only the scheduled task knows. Store the token in the website’s environment settings, not in the code, and accept the request only when it carries the token:
curl.exe -s -o NUL -w "%{http_code}" -H "X-Job-Token: YOUR_TOKEN" https://example.com/jobs/nightly-order-importExpected: a status code of 200 when the token is right. Test the wrong token too: it must return 401 or 403, not run the job. Use curl.exe explicitly on Windows, because PowerShell has its own curl alias with different options.
Plesk runs the task with the permissions of the website’s system user. Do not give that user rights it does not need.
Step 4: Make the job safe to repeat
If a run takes longer than the interval, a second run starts while the first is still going. Make the job skip when a run is already in progress, for example by writing a lock row in the database or a lock file that is removed at the end. A job that imports orders must also be idempotent: running it twice should not charge a customer twice or import the same order twice.
Step 5: Log every run
Write one line at the start and one at the end of each run, with the time and the result. Keep the log in a folder outside the website’s public path, so it cannot be downloaded. A job that logs nothing cannot be checked, and a job that logs only errors cannot show that it ran at all.
Expected: after the first scheduled run, the log has a start line and an end line with the same job name. Check the log the morning after the first real run.
Step 6: Test before you rely on it
Run the task once by hand from Plesk, using the Run Now option if the panel offers it, and check the result. Then set the schedule to a time a few minutes ahead, and watch the log to confirm the automatic run. Only then set the real schedule. Testing the timing takes minutes, and finding a broken schedule after a week takes a week.
Step 7: Watch for failures
Add a simple check that alerts you when the last successful run is too old. The check can be a second scheduled task that reads the last log line, and sends you an email if it is older than the expected interval. A missed run is a silent failure, and a check is the only thing that finds it.
Common mistakes
- An endpoint without a token. Anyone who finds the address can run your job.
- Jobs that overlap. Use a lock so a slow run does not start a second copy.
- No log. You cannot tell whether the job ran.
- Using curl without .exe. PowerShell’s alias takes different options, and the call can fail without a clear message.
- Running heavy work every minute. A job that takes a minute to run should not be scheduled every minute on shared resources.
Frequently asked questions
How often can a scheduled task run?
It depends on the plan and on how long the job takes. Frequent jobs should be short. Long jobs belong overnight.
Can a task run while the website is down?
A command-based task can, because it does not need the website to respond. A URL-based task needs the site to answer.
What if the task fails with a timeout?
Split the job into smaller batches, and log each batch. A single request that runs for minutes is more likely to time out than a series of short ones.
Should the task run as an administrator?
No. Give it the rights of the website’s user, and nothing more.
A scheduled task is a promise that a job will run on time. Make the endpoint require a token, make the job safe to repeat, log each run, and test the timing before you trust it. Then add a check that tells you when a run is missed. For the deploy that puts the job’s code on the server, read how to deploy a website with Git in Plesk.