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.
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.
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.
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.
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…
@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.
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.
Just finished debugging an unexpected mid-job stoppage which led me to this topic.
Having this would help my team (and other departments) deal with multiple batch flows. Each with variable runtimes daily due to No. of emails, ranging from 10 minutes to 2 hours.
This feature would be great for flexibility/simplicity for mandatory batch jobs.
Helps us to maximise runtime utilisation while sharing limited (1) bot.
Would save me needing to hard book starting trigger timeslots (risk wasting unused runtime) between the different departments.
I’ve been following up on this for coming up on 2 years.
The only reason I could think of this not being a feature is UiPath trying to encourage less efficient usage of licensing, driving artificial inflation of licensing requirements.
Can we please just get this very basic feature please - its been 1.5 years of me personally following up
I hope someone from UiPath sees this - although at this point I have little faith
Now sure how the ReFramework would prevent a bot from stopping 2 minutes in because it started 58 minutes late due to other processes occupying all the available machines.
The only way would be to NOT use the Stop/Kill after and have each process keep it’s own running time and it check periodically (reFramework, check before getting next transaction).
That’s not as easy in a single run process since you have to insert checkpoints regularly.
Im probably reading this wrong but describing the exact situation you are trying to overcome may help.
We have hundreds of processes running on around 10 machines, processing 10k queue items a week maybe more and not one of them i would want to only run for 20 mins? just trying to under stand this requirement.
Im strugling to under stand why you would want a process to start and only run for
20 minutes?
We interact with certain applications that will throw in random popups that can hang a bot. Even though an activitiy times out it never actually fails, just hangs indefinitely. At that point after a normal bot process time, we can safely assume a machine/process is hung indefinitely and want to kill it.
This feature would be very helpful at my company as well. We are considering building a bot that will automatically check for stuck jobs by checking the logs, but this really feels like something that should be included as part of the settings in orchestrator.