Most enterprise Azure teams have at least one workflow that has to survive a restart. An order that touches four systems, a document pipeline waiting on a human sign-off, an agent loop that calls a model several times and cannot afford to lose its place. Durable Functions has been the standard answer for years, and the programming model earned that position. What it never fully solved was the backend. Orchestration state lived in Azure Storage queues and tables that your app hosted, and the team owning the workflow also owned the partition tuning, the history bloat, and the debugging of stuck instances by reading table rows. Durable Task Scheduler is Microsoftā€™s answer to that half of the problem.
The scheduler is a separate Azure resource with its own compute and memory, purpose built for dispatching orchestrator, activity, and entity work items and storing history at scale. Your app connects over TLS secured gRPC, authenticated by managed identity, with private endpoints available when traffic must stay inside your virtual network. It is now the recommended storage provider for both Durable Functions and the standalone Durable Task SDKs, so existing orchestration code keeps running while state management moves out of your process. The result is lower CPU and memory pressure in the app, fault isolation between the workflow engine and the workloads calling it, and independent scaling of the two.
The feature most teams will notice first is the dashboard. Every scheduler ships with one, secured through role based access control. It shows orchestration status, duration, inputs and outputs, sub orchestrations and activities, and lets an operator pause, terminate, or restart an instance from the browser. Anyone who has diagnosed a hung instance through storage explorer will understand why this matters. Observability for long running workflows stops being something the platform team builds and becomes something the service provides.
The architecture fits how enterprises actually work. One scheduler can host multiple task hubs, each a logical partition of state with its own dashboard and RBAC boundary, which separates environments or teams on one billed resource. The honest caveat is that hubs on a shared scheduler share capacity, so a noisy workload in one can affect another. A local emulator runs in a container, giving developers the same orchestration and dashboard experience without an Azure subscription in the loop.
Billing inverts the usual serverless assumption. The Dedicated SKU is priced per capacity unit rather than per action, and each unit supports up to 2,000 actions per second with 50 GB of orchestration data and up to 90 days of retention. High availability requires three units, so a redundant deployment has a real monthly floor; a Consumption SKU covers lighter or spikier workloads. Payloads cap at 1 MB, which enforces the right habit anyway: pass references to large documents, not the documents themselves.
Where this becomes strategic is agent workloads. Microsoft has positioned the scheduler as the durable backend for its Agent Framework, with the dashboard exposing conversation history, tool calls, and the external event handling that human in the loop approvals depend on. Long running, stateful, resumable execution is exactly what a production agent needs and what a bare model call cannot provide. If your team ruled out Durable Functions because operating the backend was too much overhead, that objection has been addressed. The question now is which of your fragile, retry laden workflows should be the first to move.
