Orchestrator Queue Item duration check

Hi team,

How can we check the total time it took to complete each queue item in the orchestrator?

I want to find out which item took the longest time so we can troubleshoot further.

I see the started and ended columns, but looking for the exact duration, like 1min 5sec, etc

Hi @tejaskumar.darji,

You can achieve it in 2 ways.

If it a one-time activity, then proceed with the Transaction Items Export option.

  • Export all transaction items to Excel → Once you open the View Transactions page, filter to the queue/date range → Click on Export. It will download a .zip file which contains and excel file. Sort descending on the “Transaction Execution Time” column to find the longest-running item.

If it is a repeated process or you want to automate it, then I would suggest using OData API.

  • Query GET /odata/QueueItems, each item has StartProcessing and EndProcessing fields. Pull these and compute EndProcessing - StartProcessing per item, then sort.

I hope this helps.

Cheers!

Hi @tejaskumar.darji

You can calculate the duration using the Started and Ended timestamps.

For example:

Duration = Ended - Started

This will give you the exact time taken for each queue item (e.g., 1 min 5 sec). You can export the queue items to Excel/CSV and calculate the duration, then sort by duration to identify the longest-running items.

Yeah, but my perspective here is to quickly grasp the idea from the orchestrator’s view rather than exporting, sorting, and filtering parts.

Shouldn’t there be a simple, quick column added to the queue view that shows the duration?

This is a basic requirement and would help the controller team a lot.

Yes, fair point, and honestly, a Duration column should’ve existed. But even if UiPath added one tomorrow, it’d only solve half the problem: any column-based sort in the Transactions grid only sorts within the current page, and Orchestrator caps each page at 100 transactions. So “sort by Duration” would only ever tell you the longest item among those 100.

That’s the real reason the Export/API route isn’t just a workaround, it’s actually the only reliable method: both pull the entire transaction set, with no 100-item ceiling.

Cheers!

Hi @tejaskumar.darji,

You can create a separate monitoring/reporting process that pulls the QueueItems from Orchestrator, calculates the duration using the Started and Ended timestamps, and generates a report showing the processing time for each item.

This can be developed as a reusable component and implemented across multiple processes, for example at the end of each process.

Alternatively, you can create a UiPath App for this purpose, where users can select the required Queue and get the required insights based on your customization, such as average processing time, longest-running items, failed items, and other relevant metrics.

Thanks!

Hi,
You can ise it like this and check after getqueieitems
queueItem.Ended.Subtract(queueItem.Started).ToString(“hh:mm:ss”)

Dont pay heed to the AI responses.

What you are looking for is UiPath Insights.

You can make yourself a dashboard there, if you use the table view as the display option you can easily show the queue items, from whichever queues you wish, ranked by duration. I believe thats a native field in insights for queue items too so you dont need to calculate it, but you can if needed using the expressions.

You can add easy filters for the date period, queues or folders you want to look at.

I agree in principle, but creating custom dashboards is too time-consuming for the team continuously monitoring Orchestrator. With over 50 different queues across the RPA CoE, building and maintaining a dashboard for each one simply isn’t scalable.

Since the need to check transaction durations arises randomly across different queues, adding a simple ‘duration’ column directly to the standard queue view would be a much more practical and efficient solution.

Why are you assuming you are going to need a dashboard per queue?

Insights can cover the entire tenant, its only going to filter on a certain queue if you tell it to. Its actually more steps to make it only show a certain queue, by default if you select queues as part of your visualization then every queue is covered.

Right I understand the other ways to achieve the same; thank you for the detailed explanation, but my point here is: why do all this hassle? This should be directly integrated into the orchestrator by default. I mean, this is a basic parameter that users would want to glance at any time on any queue. Adding a custom dashboard here simply adds more complexity.

My point is to simply have a new column added in the orchestrator for the same purpose to avoid all this extra work.

Hi @tejaskumar.darji ,
Try these steps:

  1. Go to Queues → Transactions.
  2. Export the transaction data to Excel.
  3. Calculate Duration = Ended Time − Started Time in Excel to get values like 1 min 5 sec.
  4. Sort the Duration column in descending order to identify the queue item that took the longest time.

Thanks

Yeah, I think if you are simply asking for a duration column on the queue items overview page, in addition to the other columns, without any other context, then yeah, I agree. Thats a very simple metric to add and can even be calculated front end so would be lightweight.

If you accept the use of TamperMonkey to add custom scripts to the page I can even help write something for you to do it, I have done that elsewhere to help tweak some behaviour I want in the Orchestrator.

Given the wider context of your ask, which is to find queue items that take a longer duration, and troubleshoot etc. You want insights. Its a one off setup, so its not hassle, and you can build yourself a dashboard that can alert you to any queue items, from any queue, that are going over the average processing times.

This is compared to going over dozens or hundreds of queues, filtering by the new column you want, and then trying to see if they are above the average (which I guess you also need to just know).

Insights I think is clearly the better solution for your problem, doesn’t mean the duration column isn’t a nice to have, but it will not really solve your core problem without it still having alot of hassle in my opinion.

Makes sense, thank you so much for detailed help on this topic @Jon_Smith