Note: These limitations apply only at the workflow level and do not extend to the tenant or workspace level
Workflows and Workflow Executions
Execution Queue
Each execution first enters the execution queue. If capacity is available, it runs immediately; otherwise, it waits in the queue until capacity becomes available. Execution queue limits are defined at two levels:- The workspace level, which controls concurrency of workflows in individual workspaces.
- The tenant level, which governs overall activity across all workspaces within the tenant.
Execution Queue Exceptions
Execution Queue Exceptions
- On-demand workflows bypass the queue.
-
Workflows that include any Interactive Actions, Web Forms, or the Wait action with a timeout greater than
60seconds are not immediately added to the execution queue. Instead, they are placed in a pending state while waiting for input or a response from an external user. These pending workflows do not count toward the execution concurrency limit. Once a response is received, if the execution queue has available capacity, the workflow will proceed to execute immediately. If the queue is full at that moment, the workflow will enter the queue and wait its turn to execute. - For workflows configured to run in series, every single execution enters the main execution queue immediately upon creation. Once in the main queue, executions are then placed in a dedicated serial workflow queue, where they wait their turn to run in order
Steps
More In-Depth Explanation of Timeout Limitations
Timeouts can be defined at two levels: Step and WorkflowStep-Level Timeout
Step-Level Timeout
Note: Each step can run between
2 and 12 hours. If needed, a step can stay paused for up to 14 days. Internal steps (like, the Print action, the Flow control actions and certain Utility actions) follow the main execution timeout, while external steps (like HTTP actions, Python actions, or Bash actions) default to 60 seconds but can be set anywhere from 1 second up to the overall execution timeout.-
configuration: The step timeout is adjustable in the step settings, with a default of
60 seconds.Note: Each step can run between2and12hours. If needed, a step can stay paused for up to14days. Internal steps (like, the Print action, the Flow control actions and certain Utility actions) follow the main execution timeout, while external steps (like HTTP actions, Python actions, or Bash actions) default to60seconds but can be set anywhere from1second up to the overall execution timeout. For more information, visit the workflow limitation documentation -
What happens when time runs out?
- If a step exceeds its allowed time, it will fail resulting in the entire workflow to fail, unless ‘continue on error’ is enabled.
Exceptions- Interactive Actions and the Wait Action
Exceptions- Interactive Actions and the Wait Action
The Wait Action and Interactive Actions pause the workflow while awaiting user response, placing it in a pending state.
-
These steps can remain paused for up to
14 days. - If the timeout is reached, the step is automatically completed, and the workflow continues without failure.
2-hour timeout.-
It runs for
1 hour, then pauses at step with an Interactive Action. -
The step containing the Interactive Action remains paused for
3 hours. - Once the user responds, the workflow resumes and completes execution.
-
The total execution time is recorded as
1 hour(excluding the3-hourpause), meaning the workflow does not time out.
Workflow-Level Timeout
Workflow-Level Timeout
Specifies the maximum duration a workflow can run before it is terminated.
-
configuration: Set in workflow settings under ‘Execution Timeout (in hours)’ field.
- The default timeout is
2 hours. - The maximum limit is
12 hours.
- The default timeout is
-
What happens when time runs out?
- If a workflow exceeds its configured execution time, it will fail with a timeout status.
- Any steps that have not yet started will remain in a ‘not started’ state.
- If a workflow times out while a step is still running, that step will not be cancelled. It will continue to run to completion or failure, even after the overall workflow has timed out.