How Concurrent Workflows Are Measured
Each Flowgear subscription provides a Concurrent Workflow capacity that can be allocated to Sites. The capacity limits how many top-level Workflow instances can run at the same time; it does not limit how many Workflows you can create.
A Workflow occupies a capacity slot while its Runtime instance is running. The slot is released when that instance stops.
Production capacity
The production Concurrent Workflow pool covers enabled and externally invoked Workflows, including:
- Always On, listener, and scheduled Workflows.
- API-invoked Workflows.
- Workflows invoked through MCP.
- Other production Runtime invocations.
An Always On Workflow occupies a production slot while its Runtime instance remains active, including while it waits for the next trigger event. API and MCP invocations occupy a slot only for their execution period.
Because API and MCP traffic can arrive in bursts, leave enough unused capacity for expected peaks. For a long-running process behind a synchronous API, consider using a queue so the initial request can return promptly and another Workflow can process the task.
Authoring capacity
The v2 Runtime uses a separate Concurrent Workflow pool for Debug and Preview runs. Its capacity is 20% of the Site's production allocation, rounded down, with a minimum of five.
The v1 Runtime uses the production pool for manual runs. For the v2 Runtime, see Activation Modes and Timeouts for the difference between Debug, Preview, and production execution.
Sub-Workflows
In the v1 Runtime, the Workflow Node runs serially by default and does not consume an additional production slot. When you enable its parallel mode, each concurrently running child Workflow consumes a slot.
If the parent occupies one slot and its Workflow Node runs up to five child Workflows in parallel, the group can consume up to six production slots. When no slot is available, a parallel child waits until capacity becomes available.
The v2 Runtime Sub Workflow Node does not expose the v1 Runtime's parallel mode.
When capacity is exhausted
When a new top-level invocation needs a slot and the applicable pool is full, Flowgear rejects it with HTTP status 429 and the following message:
The maximum number of concurrent tasks has been exceeded or this Site is not allocated to an active subscription.
Always On, listener, and scheduled activations can wait or retry according to their activation path rather than surfacing the error directly to a caller.