Schedule stop after

Feedback Orchestrator
1

Would like a True Stop After (the actual start time, NOT the trigger time). I can understand why some processes would need to to complete by a certain time. This is actually a Stop at 1:20 p.m. NOT a stop after. If for some reason it is hung it will Stop/Kill after x time, so that machine can be used by the next process and not tied up indefinitely.

The whole purpose of scheduling is the get a bot to run… According to your documentation below, it’s merely a request the may or may not be fulfilled. We have financial processes that MUST run regardless of when they start.

Turn on the Schedule ending of job execution toggle to select a job termination strategy.
Note

  • The amount of time specified here elapses according to the specifications, even if the job is queued. For example, if you schedule a job to run at 1 p.m. and set it to stop after 20 minutes, the job stops at 1:20 p.m. even if it had stayed in a queue until 1:15 p.m., and then started.
6

Hi all,

Are there any updates or progress on this?

I see this as an essential feature and need this implemented as there is no way of doing this without creating your monitoring service to do this via the API.

Thanks

7

I haven’t heard a peep on this. I have a friend who just took a job with UiPath so I may bug him on this and a few other things they really need to implement.

Having the option to end after a length of time from the trigger time is OK for processing that access a website that goes down nightly for maintenance so to kick off a process at 9 PM and give it 2 hours only becuase the website is unavialable at 11 is probable useful.

We run bots and want them to always run, just if they are stuck or something to end after a period of time to free the robot up for another process. So for us I want the end time to be based on the actual start time… We don’t have an unlimited supply of robot machines.

1 Like
8

There is functionality for this already. You can tell a process to stop after a period of time after starting and it will send a stop request and can have it kill the job if it doesnt stop after another set period of time. Its based on when the job starts though, not to stop at say 11pm.

9

The existing functionality is not based on when the job starts, it is based on the trigger time. If you have a busy day with long running processes, a job can be dleayed starting thus eating into the time allotted. That is per UiPath as I opened a help ticket on it and they replied that’s by design. Works in half the cases maybe…

1 Like
10

I did not know this, all the stuff I have used it one before is queue based, not time trigger based. My apology.

11

@Jon_Smith it makes sense that you may not have encountered this issue if you do not have frequent overlaps or if you have very short processes.

With a queue trigger this feature’s risk still exists so I would encourage you to review whether it will impact your processes and what the consequences could be.

12

I have long running processes, I have short running ones. I’ve had situations where I needed to stop a process after x time, but it usually because the application automatically logs you out after x hours, so the Queue based approach works fine.
Time triggers for me are just for dispatchers usually.

I dont see any impact as I feel this is a someone niche requirement, although since its already on queue triggers I dont see why it cannot be added to time triggers.