Timeouts¶
A range of timeouts have been implemented for workflow execution, each with a default value designed to maintain system stability and ensure reliable operation.
You can change the default timeout values based on business needs by updating the relevant system setting parameters. Once you make changes, they will take effect after the cache is refreshed. All timeout values are set in seconds. For more details, see the Workflow System Parameter Page.
Note: Adjusting timeout values should be done with care, as increasing them may lead to transaction timeouts and could negatively impact system performance.
All parameters in the table below are configurable on the Workflow System Parameter Page; adjust them only when you understand the impact on stability and related system limits. Always ensure values remain compatible with other system limits (e.g., API Gateway Timeout).
| Timeout Type | Parameter Name | Default Value | Description |
|---|---|---|---|
| Sync Timeout | SINGLE_THREAD_SYNC_EXECUTIONS_TIMEOUT | 300 seconds (5 minutes) | Maximum execution time for Cascade Workflows triggered synchronously ('Before' or 'After'). If chained workflows exceed this duration, an error occurs. Tip: Ensure this value is less than the API Gateway Timeout. |
| Async Timeout | SINGLE_THREAD_ASYNC_EXECUTIONS_TIMEOUT | 900 seconds (15 minutes) | Maximum execution time for Cascade Workflows triggered asynchronously. If the workflow exceeds this duration, it will fail. |
| Async Thread Delay | ASYNC_THREAD_DELAY_SECONDS | 15 seconds | The thread sleep duration, specified in seconds, is applied when there are no asynchronous jobs to process before attempting to retrieve the next batch. |
| Debug Timeout | DEBUG_TIMEOUT_DURATION | 480 seconds (8 minutes) | Maximum duration allowed when running workflows in debug mode (Inspect BPA). If debugging takes longer than this period, the process will time out, and you will receive an error message: "It took long time to inspect the Workflow. Please limit the amount of data and try again". Tip: Consider the gateway timeout when setting this value. Setting it too high value may impact system stability. For additional tips see the troubleshooting timeout limit section. |
| ML Request Timeout | ML_REQUEST_TIME_OUT_SECONDS | 60 seconds | Time the system waits for a response to ML requests made from IFS AI Tasks. If not completed in this period, the request times out. |
| BPA System Parameters Refresh Interval | BPA_SYSTEM_SETTING_REFRESH_INTERVAL | 3600 seconds (1 hour) | Specifies the frequency at which the BPA system parameters cache is refreshed. Parameter changes will automatically apply when the refresh interval expires for each pod. Setting the value too low can negatively impact performance due to frequent refresh operations. In a multi-pod environment, the refresh interval applies independently to each pod. Since pods may start at different times, one pod's refresh interval can expire before another pod's interval, causing parameter changes to take effect at different times across pods. |
| Pod Heartbeat Interval | BPA_POD_HEARTBEAT_INTERVAL | 3600 seconds (1 hour) | Interval (in seconds) between pod heartbeat updates. The heartbeat runner uses this interval to refresh pod presence in the database so the system can track which pods are active and detect when a pod has expired. Adjust based on your deployment. Lower values increase Database load and higher values may delay pod expiry detection. For more information, see Heartbeat Runner. |
| Pod Cutoff Delay Interval | BPA_POD_CUTOFF_DELAY_INTERVAL | 600 seconds (10 minutes) | This is an additional buffer added to the Pod Heartbeat Interval when checking whether the other OData Provider instances are inactive. Modifying this value affects how long the runner waits before retrying a failed heartbeat. For more, see Heartbeat Runner. |