Complete guide to scheduling tasks in Windows with schtasks

Scheduling tasks in Windows with schtasks is one of those things that, once you master it, makes you wonder why you've been doing repetitive tasks manually for years. Backups at odd hours, scripts you run every morning, services you have to restart after an outage—all of that can be automated with a single command.

The `schtasks` command is the command-line interface for the Windows Task Scheduler, allowing you to create, modify, list, run, and delete tasks on both your own computer and remote machines on the network. Let's explore it in detail, with clear examples and explanations of each key parameter so you can get the most out of it, from simple automations to advanced scenarios involving users, permissions, and remote computers.

What is schtasks and what can it do for you

Schtasks.exe is the command-line tool that Windows uses to communicate with Task Scheduler. With it, you can schedule a program, script , or command to run automatically at a specific date and time or on a set schedule, without having to access the graphical interface.

With schtasks you can schedule recurring tasks (every X minutes, hours, days, weeks, or months), tasks that run when the system starts, when a specific user logs in, when the computer is idle, or even in response to system events. Furthermore, you can start tasks under different user accounts (including the SYSTEM account) and on remote computers.

The basic operations of schtasks are grouped into six main subcommands, which are the ones you will use 99% of the time:

• schtasks change: modifies properties of an existing task (program to run, user, password, interactive mode…).
• schtasks create: creates a new scheduled task.
• schtasks delete: deletes a task from the scheduler.
• schtasks end: stops the program that is running a task.
• schtasks query: displays the team's scheduled tasks.
• schtasks run: forces the immediate execution of a task that has already been created.

Behind these operations are a host of parameters that define the frequency, start and end dates, the user under whom the task is executed, the remote team, delays, duration, privilege levels, and more. We'll break them down for you below.

Permits required to work with schtasks

Before you start creating tasks like crazy , it's important to be clear about what permissions you need, because otherwise you'll end up with tasks that are created but not executed or that fail silently.

On the local machine, to manage all tasks (view, create, modify, and delete them), you need to be a member of the Administrators group. A standard user can create their own tasks in some cases, but if you want full control over the system, do so from an account with administrative privileges.

On remote machines, the process is similar : the account you use must be an Administrator on the remote machine. You can run the command from your machine and use the /s parameter to specify the target machine and /u and /p to provide administrator credentials for that machine or domain.

The /u parameter only works correctly when the local and remote computers are on the same domain or on domains with configured trust. If there is no trust relationship, the remote computer cannot authenticate the account you pass it, and the task will be misconfigured or empty, even though it appears to have been created.

Additionally, the task itself must have sufficient permissions to perform its function. By default, tasks run under the current user or the user you specify with `/u` . If you want them to run under a different account or directly with system privileges, you must use the `/ru` (Run As User) parameter and, typically, `/rp` to specify the password.

General syntax of schtasks and key parameters

The syntax for schtasks is quite extensive , but it always follows the same pattern: a subcommand, followed by parameters that define what, when, where, and with what permissions the task is executed. The general format for creating tasks is:

schtasks /create /sc <tipo_programación> /tn <nombre_tarea> /tr <comando_o_programa>

The fundamental parameters when creating a task are the following:

• /sc: type of programmingTypical values:
  • MINUTE: every N minutes.
  • HOURLY: every N hours.
  • DAILY: every N days.
  • WEEKLY: every N weeks.
  • MONTHLY: every N months.
  • ELEVEN: a single execution.
  • ONSTART: in each Boot of the System.
  • ONLOGON: when a user logs in.
  • ONIDLE: when the system has been inactive for X minutes.
  • ONEVENT: in response to a specific event in the log.
• /tn: Unique task name. Can include folder path (for example, "MiCarpeta\BackupDB"). Maximum 238 characters.
• /tr: Full path to the executable, script, or .bat file to be executed. If you do not specify a path, it will be assumed. %SystemRoot%\System32Maximum length 262 characters.
• /s: remote computer (name or IP). If you don't use it, you're acting on the local computer.
• /or: credentials with which the schtasks command itself is executed (for remote programming).
• /p: password of the user indicated in /uIf you don't provide it, the console will ask for it.
• /ru { | system}The account under which the task will be executed. You can use a domain user, a local user, or the account System.
• /rp: password for the account indicated in / ruIt is not used with /ru Systembecause the SYSTEM account does not have a password.
• /mo: frequency modifier within the programming type (how many minutes, hours, days, weeks or months).
• /d: specific day or days for WEEKLY or certain modes of MONTHLY (for example, /d MON,FRI).
• /m: specific months (JAN-DEC or * for all).
• /st: start time in 24-hour format (HH:MM).
• /et o /du: end time or maximum duration for schedules by minutes/hours.
• /sd y /ed: start and end dates according to the system's regional settings.
• /Item: makes the task run only if the execution user is logged in interactively.
• /np: does not save password; the task runs non-interactively and only with local resources.
• /z: automatically deletes the task when the schedule ends.
• /rl: privilege level (LIMITED or HIGHEST).
• /f: forces the creation or modification, overwriting without asking for confirmation.

There are more advanced parameters (XML, backwards compatibility, delays with /delay , HRESULT codes, etc.), but with the above you can cover virtually any standard scenario.

Schedule tasks with different frequencies

One of schtasks' strengths is its flexibility in defining the frequency of execution. You can adjust it from runs every few minutes to releases on the last day of certain months or the second Sunday of each quarter.

For scheduling by the minute , use /sc minute . The /mo modifier specifies how often the task is run. If you don't specify, the default value is 1 minute.

Example interval 20 minutes: schtasks /create /sc minute /mo 20 /tn "Security Script" /tr \\central\data\scripts\sec.vbs

Example with time slot: schtasks /create /tn "Security Script" /tr sec.vbs /sc minute /mo 100 /st 17:00 /et 08:00 /k

For scheduling, use `/sc hourly` , and again `/mo` indicates how often. For example, to run MyApp every 5 hours starting March 1st:

Example schedule for 5 hours: schtasks /create /sc hourly /mo 5 /sd 03/01/2002 /tn MyApp /tr c:\apps\myapp.exe

In daily schedules ( /sc daily ) you can use /mo to space out the executions. For example, run MyApp every 12 days starting from a specific date:

Spaced daily example: schtasks /create /tn MyApp /tr c:\apps\myapp.exe /sc daily /mo 12 /sd 12/31/2002 /st 13:00

Weekly scheduling is defined with `/sc weekly` , combining `/mo` (week interval) and `/d` (days of the week: MON, TUE, WED, THU, FRI, SAT, SUN, or *). For example, to launch MyApp every other Friday:

Weekly example (every 2 weeks): schtasks /create /tn MyApp /tr c:\apps\myapp.exe /sc weekly /mo 2 /d FRI

There are several options for monthly schedules :

• By a specific day of the month (1-31) with /sc monthly y /d.
• Per week and per day (FIRST, SECOND, THIRD, FOURTH + /d day) and optionally /m with the months.
• Last day of the month with /mo LASTDAY y /m for specific months or * for all.

Monthly example (last day of specific months): schtasks /create /tn MyApp /tr c:\apps\myapp.exe /sc monthly /mo LASTDAY /m FEB,MAR /st 18:00

Special triggers: one-time, startup, login, and idle

You don't always want a recurring task . Sometimes you only need to run something once at a specific date and time. That's where the ` /sc once` command comes in , which requires a `/st` and, usually, a `/sd`.

Single execution example: schtasks /create /tn MyApp /tr c:\apps\myapp.exe /sc once /sd 01/01/2003 /st 00:00

The ONSTART type (/sc onstartThis makes the task run on every system startup, ideal for maintenance scripts, monitoring, or custom services:

Example OnStart: schtasks /create /tn MyApp /tr c:\apps\myapp.exe /sc onstart

ONLOGON (/sc onlogonThis executes the task when a user logs on. You can use it to launch environment scripts, mount network drives, start internal applications, and more. For example, on a remote computer:

Example remote OnLogon: schtasks /create /tn "Start Web Site" /tr c:\myiis\webstart.bat /sc onlogon /s Server23

ONIDLE (/sc onidle) triggers the task when the computer has been inactive for a period of time, which you define with /i in minutes. For example, to start MyApp when the device has been inactive for 10 minutes:

Example OnIdle 10 min: schtasks /create /tn MyApp /tr c:\apps\myapp.exe /sc onidle /i 10

Create tasks with specific privileges: alternate user and SYSTEM

A very powerful use of schtasks is to launch tasks with accounts other than the one you're currently using. For example, you can schedule maintenance under an administrator account even if you're logged in with a limited user account, or run processes with the SYSTEM account to have elevated privileges.

To run a task with a different user account , use the /ru parameter along with the password in /rp . For example, to launch MyApp weekly on Tuesdays as Admin06 on the local machine:

Example /ru alternative: schtasks /create /tn MyApp /tr myapp.exe /sc weekly /d TUE /ru Admin06

On remote machines, /uy and /p control who schedules the task , while /ru defines under which account it will run. These are distinct concepts that should not be confused.

• /u: credentials to run the schtasks command and create the task on the remote.
• / ru: account with which the task will be executed when the time comes.

Remote example with different accounts: schtasks /create /tn MyApp /tr myapp.exe /sc daily /mo 4 /s Marketing /u Marketing\Admin01 /ru Reskits\User01

If you want to use the SYSTEM accountwho has very high privileges, it is enough to specify /ru System Without a password. For example, to run MyApp on the 15th of each month as SYSTEM:

Example as SYSTEM: schtasks /create /tn MyApp /tr c:\apps\myapp.exe /sc monthly /d 15 /ru System

Keep in mind that processes running as SYSTEM are not interactive: the user doesn't see any windows or can't interact with them. They are ideal for services, maintenance scripts, or system tasks, but not for opening user-visible applications.

Manage existing tasks: change, run, list, and stop

Once you have created tasks, schtasks offers several subcommands to manage them without opening the Task Scheduler graphical console.

To change the properties of an existing task, use schtasks /change . You can modify the program it runs, the user it runs on, the password, or specify that it only runs in interactive sessions.

• / tr: new executable or script.
• / ru: new execution account (user or SYSTEM).
• /rp: password for the account in /ru.
• /Item: marks the task as “only when the user is logged in”.

Example script change: schtasks /change /tn "OpenWebinarsSchedule" /tr C:\Users\OpenWebinars\Documents\Release\nuevo_script.bat

If you want to run a task right now , ignoring its schedule, you use `schtasks /run` . This execution does not alter the next scheduled date.

Run immediately: schtasks /run /tn "OpenWebinarsSchedule"

To list team tasks , use schtasks /query . You can get a simple list, a table, or a detailed list format:

• schtasks /query → basic list.
• schtasks /query /fo LIST /v → detailed list, very useful for troubleshooting.

If a task is running a program you want to stop , you can use ` schtasks /end` . You only need the task name:

Force task stop: schtasks /end /tn "OpenWebinarsSchedule"

And when you no longer need a task , you delete it with schtasks /delete . You can delete a specific task or all of them (carefully):

• schtasks /delete /tn OpenWebinarsSchedule /f → Delete that task without asking for confirmation.
• schtasks /delete /tn * /f → Deletes all scheduled system tasks.

Persistence through scheduled tasks (technical and safety vision)

An advanced and sensitive use of schtasks is creating tasks as a persistence mechanism: configuring a program or script to run periodically or at system startup, even if no one logs in. This is useful for legitimate administrators, but attackers also use it, so it's important to understand it well from a cybersecurity perspective.

A scheduled task in Windows is simply an instruction for the system to launch a command, script, or executable at a specific time or on a recurring basis. If that task is defined using the SYSTEM account and a very short frequency, you can make a binary file run continuously even if someone closes it.

Example persistence (SYSTEM every N minutes): schtasks /create /ru "SYSTEM" /sc minute /mo <minutos> /tn "<nombre>" /tr "<comando>"

Breaking down the previous order:

1. /ru «SYSTEM»: executes the task with the SYSTEM account, that is, with very high privileges.
2. /sc minute: type of programming in minutes.
3. /mo: repetition interval, for example 10 for every ten minutes.
4. /tn « »: identifying name of the task, which can be disguised as something innocent if someone wants to go unnoticed.
5. /tr « »: program or script to be executed (full path with arguments).

There are examples where schtasks are combined with tools like plink.exe to establish reverse connections, port tunnels, and the like, configured to relaunch periodically. From a defensive standpoint, periodically review the scheduled tasks with schtasks /query /fo LIST /v and the event viewer is mandatory to detect this type of use.

From AT to schtasks: why you shouldn't use AT anymore

For years, Windows included the AT command for scheduling tasks. In modern versions, this command is officially deprecated, and the command prompt itself tells you this when you try to use it: “The AT command is deprecated. Use schtasks.exe instead.”

AT allowed programming simple commands by specifying only the time, date, and the command to execute. For example, to copy documents to another drive every midnight:

Classic AT example: at 00:00 cmd /c copy C:\Documents\*.* J:\MyDocs

You could also list and delete AT tasks using variations of the same command (by ID, on remote machines, etc.). However, it didn't come close to offering the flexibility, granularity of permissions, or advanced options that schtasks provides.

In Windows 10 and later, AT still exists only as a compatibility wrapper, but it returns messages that the request is not supported. If you work with older versions of Windows where it still functions, it's recommended to migrate your automations to schtasks, which is the supported and much more powerful tool.

Schtasks versus the Task Scheduler graphical interface

Everything that schtasks does can also be done from the Task Scheduler graphical console (opens) taskschd.msc from Run), but using the command line has clear advantages: you can automate deployments, generate reusable scripts, apply changes in bulk, or work against remote teams without sitting in front of them.

A very practical approach in mixed environments is to combine both worlds: you create a base task from the graphical interface to understand all the settings, export it to XML, and then use schtasks with the /xml parameter to deploy copies, adjusting only what is necessary (user, dates, etc.).

You can also integrate schtasks into .bat or .ps1 scripts along with other maintenance tasks: cleaning logs , restarting services, launching backups or notifications, all triggered by a single scheduled task that calls a master script.

If you manage many machines or users , mastering schtasks and task automation programs will save you from getting up early to perform manual backups, prevent oversights, and reduce the risk of human error from repeatedly performing the same actions manually. It's literally teaching the system to do for you what steals your time every day.

A good understanding of schtasks, its programming parameters, and the interplay between /u, /ru, local and remote permissions allows you to automate almost any routine in Windows accurately, safely, and reproducibly, letting the computer do what it does best: follow instructions to the letter 24/7.