Runtime Policies

Runtime policies control admission and total workflow behavior.

<config concurrency="4" rate-limit="100/1m" timeout="30m" queue="orders" />

Concurrency limits simultaneously executing runs for the workflow. Rate limits control how frequently queued runs become eligible. Queue policy preserves durable waiting when capacity is available; a full queue rejects admission explicitly. Timeout covers the complete workflow, including retries and waits governed by its contract.

These policies do not replace <for-each concurrency> or <parallel concurrency>; those limit work inside one admitted run.

Configure workflow-wide policy

<workflow id="orders" name="Process orders" version="1.0.0">
  <config
    concurrency="4"
    rate-limit="100/1m"
    timeout="30m"
    queue="orders"
  />
  ...
</workflow>

Concurrency limits actively executing runs for the same workflow ID across processes sharing the state store. A run waiting durably for retry, approval, or child work releases capacity and reacquires it when ready.

The rate limit is a strict rolling window on first execution starts. It is not an average and does not limit individual HTTP requests inside a run.

The queue attribute names a durable FIFO scheduling lane; it is not services.queue and does not expose a public messaging queue.

Understand timeout accounting

The workflow deadline begins at first execution start. Queue time before execution is excluded. Retry delays, approvals, synchronous child waits, and lifecycle finalization after start count toward the deadline.

A workflow timeout is a durable failure outcome and can trigger on-error followed by on-complete.

Layer concurrency deliberately

Workflow concurrency controls runs. <parallel concurrency> controls sibling steps within one run. <for-each concurrency> controls active iterations. Configure each layer based on the resource it protects instead of setting every number to the same value.