I’m reaching out for support regarding a recurring issue I’m experiencing with a group of robots executed via Task Scheduler using a .BAT file. For the past few days, I’ve noticed that every morning when I check the Virtual Machine (VM) where the robots are hosted, the production process hasn’t completed as expected.
When I access the VM, I find the browser (Chrome or Edge) stuck on the login page of the web portal, and the robot status remains “WORKING” indefinitely. This issue affects one robot at a time, but since I have around 18 robots scheduled, it blocks the subsequent executions. Unfortunately, there’s no timeout or forced stop mechanism in place, so the process hangs without triggering any error notifications.
A few important details:
These robots are transferred to another machine after my shift ends to allow usage of RDCMan, UiPath, and Computer Vision without issues.
Each morning, I reconnect the VMs to my equipment to monitor overnight executions.
The issue consistently occurs during nighttime runs.
We use Chrome as the default browser, as recommended by the provider, and this seems to be where the problem originates.
There was a scheduled maintenance on the server hosting the VMs, but the automation processes were not affected.
Here’s what we’ve tried so far:
Cleared cache in both Chrome and Edge.
Monitored VM performance during day and night—IT confirmed no anomalies.
Split the robots between Chrome and Edge—issue persists.
Manual executions work fine during the day, with only minor portal loading delays.
Updated both browsers to the latest versions.
Updated UiPath browser extensions.
Despite these efforts, the issue remains unresolved. Has anyone encountered a similar scenario or have suggestions on how to implement a timeout or error handling mechanism that could prevent the process from hanging?
Any insights or recommendations would be greatly appreciated!
Did you happen to check system/application logs in event viewer? Logs in there may shed some light on what is happening around the time of process execution.
Also, when you try to login manually, you are able to do it? This issue only happens when you run the automation, right?
Please confirm if this automation has ever worked for you successfully in the past? If not, there is a good chance issue is with automation flow which is causing it to go in infinite loop and thus the response like this.
To resolve the issue of robots getting stuck on the login page and blocking subsequent executions, implement the following:
Login Timeout Mechanism
Use a Parallel activity in UiPath to set a timeout for the login process. One branch performs the login; the other waits (e.g., 2–3 minutes) and then throws an exception if the login hasn’t completed. This prevents the robot from remaining stuck in a “WORKING” state.
Login Page Detection
Add an Element Exists or Image Exists activity to detect if the login page is still visible after the timeout. If it is, exit the process or log the error and stop the job using Terminate Workflow.
Browser Session Cleanup
Before launching the browser, use Invoke Code or a .BAT command to kill all existing browser instances:
Watchdog Robot or Script
Create a lightweight monitoring process that runs on a schedule (e.g., every 30 minutes) to:
Check for jobs stuck in “WORKING” status beyond a threshold (e.g., 10 minutes)
Terminate them via the Orchestrator API or Task Scheduler script
Optionally send an alert via email or Teams
Use Orchestrator Runtime Limits
If using Orchestrator, configure a job runtime limit so no process can exceed a defined execution time. This adds a safety net even if internal timeouts fail.
Improve Error Logging
Capture a screenshot and log details when the login fails or times out. This helps identify unexpected UI changes, alerts, or failures during night runs.
Ensure Active RDP Session (If Using CV)
If Computer Vision is used, keep the RDP session active using a script (tscon) or schedule an “unlock” process to avoid blank or unrendered UI issues at night.
Migrate to Orchestrator Triggers (Recommended)
Transition from Task Scheduler to Orchestrator time-based triggers. This allows better error handling, retries, and centralized monitoring.
Can you try with other approach as well before starting the execution, use kill process activity to close the browsers.
And check is there anything you are doing in loop or reading any overdata files.
it is better to use debug the code if issue is coming continuously.
if still issue occurs raise a ticket to UiPath support team
For the moment I didn´t use a kill porcess activity before starting an execution. But now you mentioned is not bad I idea, I will try to do it an see how this result, because today the issue again appears during my monitoring now is stuck in other execution. Now we are here talking about I was in other robots, a kill process activity that loop the task manager to find excel or other app in custom way, I think I am going to test it with that. Thanks for give an idea. Let me see how far this issue will continue.
Hello, I check the log execution but only describe when the execution start, we can see any other log message I used just when start and is stuck like nothing more than that. Apart, as you mentioned, and yes I tried the manual way and works, adding that is the portal where the major of our coworkers use to check different stuff. So for them works perfectly, and the portal needs to work in the best way also beacuse during night shift there are not employee to use the web portal, one of the reason we scheduled during night to avoid the massive transactions or interactions between robots and cowokers
Awesome idea, I am gointo apply it and see what are the results. I forgot this tool, only reading the execution log to see information about my executions. Thank you for your advice
Really good advices, I will try to apply them, but all of this type of actions need to be consulted before with my Supervisor and Manager. However thank you, I will take a note of these options you recommend. Thank you to take the time in respond, I really appreciate it
@Efrain_Caceres In my opinion, the best option from Bhavesh’s list is the last one — moving your schedules over to Orchestrator triggers.
Once you’re using triggers, you can:
Enable “Stop After” – This tells Orchestrator to send a graceful stop signal to the job after the set time. The job gets a chance to clean up and exit normally.
Enable “Kill After” – If the job still hasn’t stopped after the “Stop After” time, this will force-terminate it. This prevents endless hangs and frees up the robot for the next run.
Turn on “Reassess conditions and start new jobs if possible” – This lets Orchestrator immediately check the trigger conditions again and start a new job if they’re still valid, instead of waiting for the next scheduled time.
One note: if a job is killed mid-transaction, the transaction may be marked as Abandoned in the queue. To handle that, you can enable Auto Retry in the queue’s properties so those items are automatically retried.
Example timeline:
08:00 AM – Trigger starts a job.
08:30 AM – “Stop After” kicks in → graceful stop signal sent.
08:33 AM – Job still running → “Kill After” kicks in and force-terminates it.
Transaction in progress gets marked Abandoned.
Auto Retry in queue detects the abandoned item and requeues it for processing.
“Reassess conditions” sees trigger conditions still valid → starts a fresh job without waiting for the next scheduled time.
This setup gives you built-in timeouts, automatic recovery from stuck runs, and ensures your queue keeps moving without manual intervention.
edit* sorry my original response repeated itself, if you need any help implementing triggers/updating your process to use the framework please feel free to shoot me a PM
Okey Community let me put on the table what I did until today. I was checking the first two advices. For the moment I added to my automations, a dynamic kill the process loop where I need to check the following processes: EXCEL, MSEDGE, CHROME and INTELISIS(custom software for accountable things). Right now Intelisis enviroment works good it showed that all the transactions are registered without any issue, however we are in the same place again, I found stuck the BROWSER with the portal I need to access. I tried as mentioned to locate my invoke workflow at the beginning of the configuration execution and also before to login or in this case open the browser. Results are the same. Now I used the Diagnostic Tools and this show me the next.
As you can see in hour range of 7:46 pm where my robot start the execution it works and is not showing erros until we start the next execution because two executions intances can be running at the same time if a previous one is stuck or stil in working. Like the next picture
The common of the Event logs show me the same case for every day I did an execution doesn’t matter if start first, in the middle or at the end. This is like a gamble, we don’t know what execution will be stuck until occurs.
We were in contact with the provider yesterday to see if the license can be related, he mentioned maybe is because we are using a attended license, and when I leave my shift this can´t work properly, but my doubt here this was working well the last year when I arrive to this position and also before my arriving, then for me that part not make sense at all. I think is something related with the server maintenance from the last weekend because as mentioned we have production in the accountable software and the computer vision works for it. That is my update. I going to start testing the orchestrator advice to see the result.
As you can see the task manager, shows mutiple MSEDGE instances of the same process, I was reading other forums, and the research results like most of the time multiple tabs are opened or stuck but this needs to be stopped by the Kill process loop that Issues to stop them one by one. I am stuck here for the moment @_@
Well community, I hope everybody are well. Let me inform you that I found the possible issue that we were discussing. As we talked before, the focus point of this was the platform, but most of the time in the journey of the automation, I forgot (My own case)to review tiny detail. Yesterday, checking the logic behind the workflow that work with the portal I found that a Retry Scope activity has a timeout with 1Millon seconds, for some reason this was there, the ironic part of this, is that I don´t touched the automation in month before this. Well I did the change and show good result, however I report to the Platform support, it doesn´t matter if I found this the portal show still some delay when it is loading the login, in consequence of that I need to use Retry scope with 4 attemps.
Also I am implementing the advices that all of you post here in this topic, so I am grateful to all of you because apart I learned some stuff I want to apply with the new automation are coming. For the moment I can’t say the issue is solved until some days of monitoring the changes I did.
yeah, that does make sense why it was stuck. It was going in an almost infinite loop there. Changes that you did should work now, but its good to monitor for few days.
Once confirmed, kindly consider marking post that helped as solution so this topic can be closed and help others facing similar issues.
It sounds like you’ve already done a thorough round of troubleshooting, so the next steps might involve adding a bit more resilience to the automation process itself.
A few suggestions:
Implement a timeout – In UiPath, you can wrap the login step and main workflow in a Retry Scope or set the TimeoutMS property on critical activities. This will force the process to fail and move on instead of hanging indefinitely.
Add a watchdog process – Schedule a separate lightweight robot or script that periodically checks whether each robot is still progressing (e.g., by log file update time or process handle). If stuck, it can kill the browser/process and trigger a restart.
Graceful failure notifications – Configure an error-handling workflow that sends an email/Teams/Slack alert when a login attempt exceeds a threshold time or if the same screen is detected for too long.
Browser automation tweaks – If Chrome is freezing at login, try adding steps to explicitly clear cookies and session storage before login, or launch in incognito mode each run.
VM session state check – Sometimes, RDC disconnection or session locking affects UI automation. Ensure the VM display never turns off and that the user session remains unlocked during night runs.
If you want, I can draft you a UiPath workflow snippet that adds both a timeout and a “force close + restart” mechanism so the next scheduled robots aren’t blocked.
Hello, thank you for take the time to check this discussion, I added some of the adivce here, but I am interested in some of the one you mentioned. Those are:
Watchdog process
Browser tweaks
VM session state check.
Currently, we have to real machine that works as the main machine dependint of the situation, those machines are my machine and the other in the servers room. Inside of them we have installed RDCMAN software to maintain the machine online everytime, in morning with me during my shift and when I leaving I send them back to the other equipment to maintain on all the VM, this for the fact you mentioned that it´s related with the computer vision. But of course I want to learm little bit more if you have the time to see those draft you mentioned. Thanks
Hi community, after reviewing today the execution all is working well. So I marked as soultion the comment I mentioned about Retry Interval Time was shooting the issue. However I am going to continue reviewing all the options you mentioned here to reforce knowledge and my automations workflows.
Again, thank you to everyone to help me with my issue.
