No impact incident

UiPath: Cloud Robots (VM) experienced a partial outage affecting multiple regions

Current status of UiPath: Operational — live UiPath status

Timeline

1. Oct 26, 2026, 10:30 UTC
   resolved
   On October 26, 2026, between 10:20 and 17:30 UTC, Automation Cloud Robots (VM) experienced a partial outage affecting machine operations. During this window, actions such as starting, stopping, or provisioning VM machines may not have completed, and jobs scheduled on those machines may have been delayed or faulted. The cause was a permissions misconfiguration on a subset of the underlying infrastructure resources. Our team identified the issue, corrected the configuration, and confirmed that machine operations have been working normally since 17:30 UTC. We are reviewing how the misconfiguration was introduced and are adding checks to prevent a recurrence. No action is required on your side. If you still see failed or stuck jobs from that window, please retry them, and contact support if the problem persists.
2. Nov 4, 2026, 16:23 UTC
   postmortem
   ## Customer impact On 26 October 2026, from 10:18 UTC, Automation Cloud Robots \(VM\) machines in all regions were stopped, and machine operations \(start, stop and provisioning\) could not complete. Jobs and triggers that depended on these machines did not run or were faulted. Machine operations worked again from 11:37 UTC \(12:20 UTC for GxP\). Between 15:38 and 16:16 UTC, machine operations failed again in all regions. Most machines were back to normal by 17:30 UTC. A limited number of machines stayed stopped without this being visible in Automation Cloud Robots, and were restarted on 27 October after a customer reported the problem. Unattended jobs that were running on these machines at 10:18 UTC were stopped before they finished. Queue items those jobs were processing were left incomplete, and most were later marked as Abandoned in Orchestrator. These items remain available in Orchestrator and can be reviewed and retried. If you use queues, we recommend checking for items marked Abandoned or Failed from 26 October and retrying them as needed. Your machines, their configuration and the data stored on them were not affected. ## Root cause UiPath was responding to a security event in its internal corporate environment. As part of that response, our team disabled a large number of internal cloud subscriptions as a precaution. The action was scoped to exclude the subscriptions that run customer services, which were identified by their naming. The subscriptions that host Automation Cloud Robots \(VM\) use a different naming convention, so they were included in the action at 10:18 UTC. When a cloud subscription is disabled, our cloud provider stops all virtual machines in it and rejects any request to start, stop or create machines. This is the ReadOnlyDisabledSubscription error that some customers saw. Our earlier status page update described the cause as a permissions misconfiguration. The more accurate description is that the subscriptions themselves were disabled. After the subscriptions were re-enabled, the service resumed and started machines as normal. However, because the machines had been stopped outside the control of Automation Cloud Robots, the service still recorded some of them as running, and did not restart those. Later the same day, between 15:38 and 16:16 UTC, access was removed from the service account that Automation Cloud Robots uses to manage machines, while service accounts were being reviewed as part of the same response. During that window the service could not start, stop or create machines. Our investigation found no evidence that the unauthorized party accessed Automation Cloud Robots or customer data. The outage was caused by our precautionary actions, not by the security event itself. ## Detection Our Automation Cloud Robots engineering team became aware at 10:55 UTC, about 37 minutes after the subscriptions were disabled, through an internal notice about the precautionary action. The team detected the second failure at about 15:50 UTC, 12 minutes after access was removed. Machines that remained stopped were not detected by our monitoring. They were found on 27 October after a customer report. Because the action was taken during the broader security response, the status page was not updated until 27 October. We recognize that this delayed communication to you. ## Response * 11:37 UTC: we re-enabled the affected subscriptions \(12:20 UTC for GxP\), then restarted the pending machine operations. * 16:16 UTC: we restored the service account's access. * 17:00 to 17:16 UTC: we re-ran the machine operations that had failed, across all affected regions. This restored all machines except those still recorded as running, which are covered below. * 27 October: we identified the machines that were still stopped and restarted them. ## Follow up * Create a fool-proof mechanism for identifying the subscriptions that run customer services and those that are internal. * Make Automation Cloud Robot

Updates as published by UiPath (original).