Troubleshooting slow or queued flows<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: ; width: auto; height: auto; } } If your flows are running slower than expected, this article can help you identify and resolve the issue. Flows that run in the background are processed by flow jobs. When a flow is started or resumed asynchronously, an event is created. Flow jobs, which run every two seconds, pick up these events and execute the corresponding flows. Delays in flow processing can occur for several reasons. Following are some common causes and how to address them: 1. Event Bursts Issue: A large number of events triggered simultaneously, often due to mass imports, updates, or other events can affect many records linked to flows. This can overwhelm the system's capacity to process flow execution requests. By default, there are three flow designer jobs on each node to process the work, and it may take some time for them to complete. How to identify: Check the sysevent table for records where name=flow.fire and state starts with ready. A large number of these records indicates an event burst. Solutions: Consider using import sets instead of flows for large imports.As a last resort, increase the flow capacity to reduce the impact of event bursts. You can do this by increasing the number of nodes or the number of Flow Engine Event Handler jobs. 2. Long-running flows Issue: Some flows take longer time to complete. With the default three Flow Engine Event Handler jobs per node, new flow events may be blocked until a long-running flow finishes or reaches a waiting stage. How to identify: Look at the sys_flow_context.runtime value (sorted in descending order) to find long-running flow contexts. Also, check the sysevent table order by processing_duration and name-flow.fire to see which events are taking longer. (sysevent.instance is flow context_id) Solutions: Avoid long running flowsSchedule long running flows during periods of low system activity.Add more flow capacity. As with event bursts, this should be a last resort only. Do this by increasing the number of nodes or the number of Flow Engine Event Handler jobs 3. Busy scheduler Issue: Flows are executed via flow designer jobs, which depend on the scheduler. If the scheduler is overwhelmed, flow designer jobs may not get a slot to execute, leading to a backup in the flow queue. How to identify: Check sys_trigger and filter with name STARTSWITH flow engine event and parent != null. Note the next_action for each row; these should not be more than ten minutes in the past. If there are many scheduled jobs (sys_trigger has many rows), flow designer might not run for some time. Solutions: Lower the priority of some jobs to a priority greater than 100. This avoids contention with Flow Engine Event Handlers, which also run at priority 100.Change Async BRs to Sync BRs (before or after record updates)Add a flow job that runs at a priority less than 100. Consult with Dev-Flow Engines regarding this option. 4. Next Action on Jobs Issue: The next_action on jobs in sys_trigger with filer nameSTARTSWITHflow engine event^parent!=NULL should not be significantly in the past. Solution: Consult with the performance team and consider resetting the next action to current on sys_trigger for flow jobs. 5. Insufficient Flow Engine Event Handler capacity Issue: An old PRB workaround reduced the number of Flow Engine Event Handlers to one per node, which is not advisable. If a single flow consumes thread capacity, all other flows on that node are blocked. Solution: Consider adjusting com.glide.hub.flow_engine.event_handler.workers to three and then remove the property. Note: Beginning with the Quebec release, flow events are pinned to the node where they were produced. If a node canot process an event, it will take com.glide.nowmq.events.max_ready_wait_seconds seconds (60 seconds beginning with the Xanadu release) to delegate the event to another node. Check XML statistics for event processing on a particular node at https://<instance_name>/xmlstats.do?include=flowstats For the latest information, see General guidelines for Workflow Studio flows, subflows, and actions