Windmill vs Windows Task Scheduler and SQL Server Agent

Windows and SQL Server each ship with a scheduler. Task Scheduler is the Windows service that runs a program on a chosen computer at a set time or when an event occurs, and it is installed with every supported version of Windows. SQL Server Agent is the Windows service that runs scheduled administrative tasks, called jobs, in SQL Server and Azure SQL Managed Instance.

Windmill is an open-source, self-hostable platform that schedules and runs scripts and workflows from one place, on the workers you deploy and, on Self-Hosted Enterprise Edition, on native Windows workers.

This page is a short overview, written by Windmill. The Windows automation page compares Windmill with Task Scheduler, Power Automate and enterprise job schedulers in one table. Feel free to contact us for corrections.

Who each tool is for

Task Scheduler is for running a program or a batch file on one Windows computer, at a time or on an event such as system startup, user logon or idle time. It is already on every Windows machine and is managed from its graphical interface, the schtasks command or the ScheduledTasks PowerShell module.

SQL Server Agent is for database administrators automating work on a SQL Server instance: backups, maintenance, SSIS packages, replication agents and T-SQL or PowerShell job steps. Job information is stored in SQL Server itself. SQL Server Agent is included with SQL Server and Azure SQL Managed Instance. It is not available in Azure SQL Database, where Microsoft offers elastic jobs instead, and the SQL Server 2025 editions table lists it for Enterprise and Standard but not Express.

Windmill is for teams whose scheduled scripts span several servers, databases and languages, and who want one place to schedule them, see every run, handle failures and review changes.

Comparison

	Task Scheduler	SQL Server Agent	Windmill
Where it runs	On each Windows computer, as part of Windows.	As a Windows service next to a SQL Server instance, or in Azure SQL Managed Instance.	A central server and PostgreSQL database, self-hosted on Docker Compose or Kubernetes, or on Windmill Cloud. Jobs run on workers; Windows workers can run as a Windows service and are Self-Hosted Enterprise.
What a job runs	Up to 32 actions per task, run in sequence: start a program or fire a COM handler (the email and message actions were removed in Windows 8 and Windows Server 2012).	Job steps: T-SQL, PowerShell, operating system commands (CmdExec), SSIS packages, Analysis Services commands and queries, and replication agents.	A script in PowerShell, C#, Python, TypeScript, SQL, Bash or another supported language, or a flow of scripts with branches, loops, retries and approval steps.
What starts it	Time-based triggers (once, daily, weekly, monthly) and event-based triggers (system startup, user logon, idle). Up to 48 triggers per task.	Schedules (when the Agent starts, when the CPU is idle, one time, recurring), alerts on SQL Server events, performance conditions or WMI events, and the `sp_start_job` stored procedure.	Cron schedules, webhooks, HTTP routes, email and other triggers (Kafka is self-hosted Enterprise Edition, Postgres triggers are not available on Cloud), the API, the CLI, or a run from the auto-generated form.
Scope	One computer per task. `schtasks` and the `ScheduledTasks` cmdlets can also manage tasks on a remote computer.	Databases on the Agent's own instance. Multiserver administration lets a master server distribute jobs to target servers; it is not available in SQL Managed Instance.	One instance for all workers. Worker tags route each script or flow to the workers that should run it, for example Windows workers for PowerShell.
Run identity and credentials	A user account or group, or a built-in account such as SYSTEM, LOCAL SERVICE or NETWORK SERVICE.	T-SQL steps use `EXECUTE AS`. Other steps run under a proxy that maps to a credential.	Connection details live in resources and secrets in variables, encrypted with a workspace-specific key. For SQL Server, Windows integrated authentication uses the account the worker runs as (Windows SSPI on Windows workers, Kerberos on Linux workers). MS SQL scripts need Enterprise Edition or Cloud, and integrated authentication needs a self-hosted worker.
When a job fails	The task can be restarted a set number of times (`RestartCount`). By default a task is stopped 72 hours after it starts.	Alerts notify operators by email through Database Mail, by pager or by `net send`; Microsoft plans to remove the pager and `net send` options.	Retries on flow steps, a flow error handler, and schedule error and recovery handlers, with pre-set handlers for Slack and Microsoft Teams. The schedule error handler is available on Cloud and Enterprise Edition.
Where you see jobs	On each computer, in the Task Scheduler interface or with `schtasks /query`.	In SQL Server Management Studio, or by querying job tables such as `msdb.dbo.sysjobs`.	A Runs page per workspace with all past and future runs, and, on Cloud and Enterprise Edition, audit logs for every operation with side effects.
Permissions	Access control lists on task files. Administrators and SYSTEM can manage any task; other users manage the tasks they created.	Fixed `msdb` roles (SQLAgentUserRole, SQLAgentReaderRole, SQLAgentOperatorRole) and the sysadmin server role.	Roles and permissions on scripts, flows, apps, resources, variables, schedules and jobs, with groups and folders.
Definitions as files	A task can be registered from an XML definition (`Register-ScheduledTask -Xml`).	Jobs are defined in SQL Server Management Studio, in T-SQL or with SQL Server Management Objects.	Git sync commits scripts, flows, schedules and triggers to a repository: Cloud and Enterprise Self-Hosted, and Community Edition for workspaces with up to 2 users.

Where Task Scheduler is the better choice

One job on one machine. If a single script has to run on a single computer and nothing else depends on it, Task Scheduler is already installed and needs no server or database.
Work tied to that machine's state. Triggers on system startup, user logon or idle time, and power-aware scheduling that defers maintenance until the device is idle and on AC power, are part of Windows itself.

Where SQL Server Agent is the better choice

Maintenance inside one instance. Backups, jobs created by the Maintenance Plan Wizard, replication agents and SSIS packages are run by the instance's own Agent service, and SQL Server Agent stores job information in SQL Server itself.
Reacting to the database engine. Agent alerts fire on SQL Server events and performance conditions and can start a job in response.
Many Azure SQL databases. For Azure SQL Database, Microsoft's elastic jobs run T-SQL across servers, elastic pools and subscriptions, and enumerate the target databases at run time.

Where Windmill is the better choice

Scripts spread across many servers. Schedules for every host are defined in one workspace, each run is listed on the Runs page, and worker tags decide which machine runs what. Windows workers connect to the same server and database as the rest of the fleet.
Jobs that cross systems. A flow can query SQL Server, call an API, run PowerShell on a Windows host (Windows workers are Self-Hosted Enterprise) and wait for an approval, with each step in the language that suits it.
Failure handling you do not write yourself. Retries are a setting on each flow step, and schedules have pre-set error and recovery handlers for Microsoft Teams and Slack (the schedule error handler is available on Cloud and Enterprise Edition).
Changes reviewed like code. Git sync puts scripts and schedules in a repository, and, on Cloud and Enterprise Edition, audit logs record each operation with side effects and the user behind it.
Azure SQL Database. SQL Server Agent is not available there. Windmill's MS SQL resource connects to Azure SQL with Microsoft Entra, or on AKS with Azure workload identity and no stored password (MS SQL scripts need Enterprise Edition or Cloud, and workload identity needs a self-hosted worker on AKS).

MS SQL as a dedicated script language is available on Enterprise Edition and Cloud. On Community Edition, query SQL Server through a resource from TypeScript, Python or another language (details).

Using them together

You do not have to move everything at once.

Keep SQL Server Agent for engine maintenance and start its jobs from Windmill. An Agent job can be started with the sp_start_job stored procedure, so an MS SQL step in a Windmill flow can kick off an existing backup or maintenance job and the flow can carry on with the work around it.
Move Task Scheduler jobs one at a time. A PowerShell script's param() block becomes its typed inputs, and Import-Module installs missing modules at run time (details). Schedule the script in Windmill, tag it for a Windows worker (Self-Hosted Enterprise) or a Linux worker, and let the Task Scheduler task run in parallel until you are confident, as described in Native Windows automation without Docker, WSL, or workarounds.
Let a local task call Windmill. A Task Scheduler task runs a command line, and every Windmill script and flow has webhooks, so a task that must stay on a machine can hand the rest of the work to a Windmill flow.