Windows Task Scheduler: make your scripts run on their own

A script that renames scans or prepares a report is useful, but it becomes truly useful when it starts on its own, without anyone having to remember it. On Windows the tool for this is already installed: Task Scheduler. It is powerful and also a little daunting, with dozens of options spread across six tabs. Let's look at the ones that really matter for automating office work.

Opening the tool

Search for "Task Scheduler" in the Start menu, or type taskschd.msc in the Run window (Win+R). On the left is the Task Scheduler Library, which already contains many system tasks. It is worth creating your own folder, for example "Office", with the New Folder command: keeping your tasks apart from Windows' own makes everything easier to manage.

Basic task or full task

The right-hand pane offers two commands. Create Basic Task is a wizard with a few steps, suited to the simplest cases. Create Task opens the full window with all the tabs. Even for a first experiment I recommend the latter: the options that make the difference between a reliable task and one that fails silently are right there.

The tabs that matter

General

Here you give the task a clear name and a description explaining what it does and who created it. The key option is the choice between Run only when user is logged on and Run whether user is logged on or not. The first shows any windows but requires you to be logged in; the second works even with the session closed, with no visible interface, and asks for the account password. Run with highest privileges should be enabled only if the script genuinely needs it.

Triggers

This defines when the task starts: at a given time, every day or week, at computer start-up, when a user logs on, or when an event recorded in Event Viewer occurs. For a morning report a daily trigger is enough, perhaps only on weekdays by choosing the weekly option and ticking Monday to Friday.

Actions

This is the heart of the task: Start a program. The most common mistake is pointing straight at the .py file. It is more robust to point at the interpreter and pass the script as an argument:

The Start in field is often left blank, and it is the cause of many scripts that work when run by hand but not when scheduled: without a working folder, relative paths such as data.xlsx point somewhere else. pythonw.exe is the variant of the interpreter that does not open the black terminal window.

Conditions

On a laptop, the Start the task only if the computer is on AC power box is ticked by default. If the computer is on battery at the scheduled time, the task simply doesn't start. Decide consciously whether to leave it on.

Settings

Two options to enable almost always: Run task as soon as possible after a scheduled start is missed, useful if the PC was off at the set time, and If the task fails, restart every, which retries after an interval. Also useful is the Stop the task if it runs longer than limit, which prevents a stuck script from staying active for days.

Creating tasks from the command line

To replicate the same task on several computers, the graphical procedure is awkward. The schtasks command does it in one line:

schtasks /Create /TN "Office\Morning report" /SC DAILY /ST 08:15 ^
  /TR "C:\Python312\pythonw.exe C:\Automation\report.py"

You can also export tasks to XML from the graphical window and import them elsewhere, keeping all their settings.

Finding out whether it worked

The Last Run Result column shows a code: 0x0 means the program finished without errors. Any other value indicates a problem, but it is meagre information. To see details, enable history from the right-hand pane with Enable All Tasks History and check the individual task's History tab.

The best solution, though, is still to have the script write its own log file, with date, time and readable error messages. In my work I consider this mandatory: when an overnight automation fails to produce the expected result, the log is the only witness to what happened.

Frequent mistakes

• Network paths: mapped drives such as Z: often don't exist when the user isn't logged on; use the full \\server\folder path.
• Changed password: if the task runs under an account whose password is changed, it stops starting until you update it.
• Different environment: variables and programs available in your session may be missing in the scheduled one.
• Dialog boxes: a script that asks the user for confirmation will wait forever if it runs without an interface.

In short

• Use Create Task rather than the wizard to reach the important options.
• Specify the interpreter, the arguments and above all the Start in folder.
• Check the power conditions and enable retries after a failure.
• Use schtasks or XML export to replicate tasks.
• Have the script write a log: the 0x0 code alone is not enough.