Queue Trigger: About delay time

In guideline of Queue Trigger (https://docs.uipath.com/orchestrator/docs/about-triggers), i found below description

Once every 30 minutes a check for new, unprocessed items is performed, and whenever such items exist, the target process is triggered.

Does it mean sometime my job have to wait 30mins for trigger after queue data adding?
If yes, i think 30 minutes is too long. Should Uipath reduce this time, or allow Orchestrator’s admin setting this time by himself?

Agreed - 30 minutes is way too long considering that Transactions could be process in minutes of not seconds. This will cause a backlog in Queue Transactions. This should be configurable based on needs.

1 Like

Ok, found the solution to adjusting the Interval Time.
There is a property in the Orchestrator Web.Config File.

Here is the response from Support Team:
Yes, the “Queue.ProcessActivationSchedule” key can be used to adjust the Queue Trigger time.

Modify the “30” value and pass any value between “0-59” and then restart the IIS.


It’s better if we can change this setting via Orchestrator’s web layout but it seems impossible 'cause IIS restarting required

Please note that the trigger works instantly with new added items. That timeout applies only to unprocessed items like retried transactions… or, for example, if you disable a trigger and at some point you re-enable it. If there are already X items in queue the trigger will fire when a new item is added or at the specified interval.

I would suggest that UiPath add this clarification to the documentation page for Qeuue Trigger because people will think that new job will start when there are new items in the queue, when in fact, it starts when a new item is ADDED or at the specified interval.

Looks like we have a performance issue with the queue triggers and sometimes they are not firing in the community cloud. Hopefully they are cleared in maximum 30 mins. We aim to fix it in 20.5.