US - Orchestrator - Intermittent errors and degraded performance in Orchestrator

Update timeline

1. investigating Oct 07, 2026, 05:37 PM UTC

   We are investigating reports of intermittent slowness and errors affecting a subset of organizations in the East US region of Automation Cloud. Affected users may see pages in the Orchestrator UI fail to load (for example, the Jobs page returning "An error has occurred"), and robot operations such as queue transactions and session starts may intermittently time out. We will provide an update as soon as more information is available.

2. monitoring Oct 07, 2026, 06:13 PM UTC

   We have applied a capacity increase to the affected database infrastructure in the East US region and error rates and latency returned to normal levels. We will provide an update as soon as more information is available.

3. resolved Oct 07, 2026, 07:06 PM UTC

   We have the issue in the East US region and error rates and latency returned to normal levels.

4. postmortem Oct 14, 2026, 11:42 AM UTC

   ## Customer impact Between approximately 13:00 UTC and 18:15 UTC on October 7, 2026, customers in the US region experienced intermittent errors and slow responses in Orchestrator. Affected users may have seen Orchestrator pages fail to load, for example the Jobs page returning “An error has occurred,” and robot operations such as queue transactions and session starts may have intermittently timed out. Other UiPath services that depend on Orchestrator may also have seen slower responses or errors during this period. ## Root cause Several frequently-used Orchestrator operations each relied on a shared short-lived resource inside the database, including the routine status check that every running robot performs. As the volume of concurrent robot activity in this region grew, requests began queueing for access to that shared resource instead of completing their work. The effect was selective rather than a general slowdown: the operations that used this resource were delayed, while others continued to run normally. Because the database’s processor, memory and storage usage all remained within normal ranges, routine capacity monitoring did not indicate a problem. ## Detection Our automated monitoring detected the degradation within approximately 35 minutes of customer impact beginning, and our engineers identified the underlying contention during the event. Because this was a contention problem rather than a shortage of capacity, and all capacity indicators were normal, increasing database capacity was not expected to resolve it, and the team investigated alternatives before applying it. That assessment delayed the mitigation. ## Response Our engineering team increased the capacity of the affected database. Response times and error rates returned to normal immediately, and we continued monitoring to confirm the service was stable before closing the incident. **Time (UTC)** **Event** 13:00 Error rates and response times begin to rise for customers in the US region. 13:36 Automated monitoring detects the degradation and notifies the on-call engineering team. 13:36 – 17:29 Engineers investigate. All standard database capacity indicators — processor, memory and storage — remain within normal ranges throughout, so the cause is not apparent from routine monitoring. 17:29 A formal incident is declared and the full response team is engaged. 17:38 A public notice is published on [http://status.uipath.com](http://status.uipath.com) (Investigating). 17:31 – 17:43 Additional database capacity is provisioned for the affected region. 18:00 Error rates, response times and request latency return to normal levels. 18:11 The status page is updated to Monitoring & Customer impact ends. 19:06 The incident is closed after continuous monitoring confirms the service is stable. ## Follow up To prevent this from happening again, we are: - Changing the affected operations so they no longer depend on the shared resource. This has been rolled out to all affected systems and has substantially reduced the condition that caused the incident. - Enabling detailed database monitoring on these systems, so this class of contention is visible while it is happening rather than afterwards. - Improving our alerting so that a genuine degradation of this kind is clearly distinguishable from routine, self-correcting variation, and is escalated faster.