Is UiPath down?

UiPath Integration Service in the Australia region, where customers may have experience failures while creating new connections. The issue started at approximately 03:51 AM UTC, 12 June 2026 till 05:59AM UTC, 12 June 2026. Existing connections and running integrations are not impacted. The issue is resolved and service is healthy.

We are investigating reports of degraded performance impacting login functionality for IXP, Orchestrator, and potentially other services in the United States region. Impact: Users in the United States region may experience issues logging in to IXP, Orchestrator, and potentially other services. Our teams are working to identify the cause and will share more details as the investigation progresses.

Mitigation has been applied and performance is improving for the issue that impacted login functionality in IXP, Orchestrator, and potentially other services across the United States region. We are monitoring closely to ensure stability.

The issue impacting login functionality for IXP and Orchestrator in the United States region has been resolved. Impact: Users should no longer experience issues logging in. We will continue to monitor service health as part of normal operations. We are monitoring closely to ensure stability.

We are investigating reports of degraded performance impacting Orchestrator workflows and Document Understanding validation experiences in Europe. Impact: Users may experience degraded performance for validation tasks started through Document Understanding APIs. Exceptions for review may also be delayed or may not appear in the Build page.

We are continuing to investigate degraded performance impacting Orchestrator workflows and Document Understanding validation experiences in Europe. Our teams are also assessing the broader service impact, as additional services may be affected. We will share more details as the investigation and rollback progress.

We are continuing to investigate this issue.

We are continuing to investigate degraded performance impacting Orchestrator workflows, Document Understanding validation experiences, and Agents jobs in Europe. Impact: Users may experience degraded performance for validation tasks started through Document Understanding APIs. Exceptions for review may also be delayed or may not appear in the Build page. Users may also see Agents jobs stuck in a pending state.

We have identified degraded performance impacting Orchestrator workflows, Document Understanding validation experiences, and Agents jobs in Europe. Impact: Users may experience degraded performance for validation tasks started through Document Understanding APIs. Exceptions for review may also be delayed or may not appear in the Build page. Users may also see Agents jobs stuck in a pending state. Our teams are working on mitigating the issue and assessing the broader service impact, as additional services may be affected. We will share more details as mitigation progresses.

A fix has been applied, and the issue impacting Orchestrator workflows, Document Understanding validation experiences, and Agents jobs in Europe has been resolved. Impact: Users may have experienced degraded performance for validation tasks started through Document Understanding APIs, delays or missing exceptions for review in the Build page, and Agents jobs stuck in a pending state. We are continuing to monitor service health to ensure stability.

## Customer Impact Between June 10, 2026, 14:15 and 16:35 UTC, customers hosted in the Europe region experienced delays or failures in services that rely on internal event processing. Affected functionality included: * Jobs remaining in a pending state or failing to start * UiPath Document Understanding™ operations timing out or failing * Automation Solutions installation and uninstallation operations timing out * Delays in synchronization of resources such as folders, processes, queues, and tags No data was lost during the incident. Events that could not be processed during the disruption were automatically processed after service was restored. Total duration: approximately 2 hours and 20 minutes. ## Root Cause ## Root Cause The incident was caused by a configuration issue during a planned infrastructure migration in the North Europe region. A required configuration update was not fully applied across all service components before traffic was moved to the new infrastructure. As a result, some services were unable to communicate with the messaging system they depend on, causing delays and failures in affected operations. Recovery took longer than expected because a separate issue temporarily delayed the rollout of the corrective configuration. Once the configuration was successfully applied, service was restored. ## Detection At 14:52 UTC, our messaging team observed a drop in traffic to the original backend. This was initially attributed to the normal, seasonal decline in traffic that occurs after business hours. On closer inspection it became clear this was a genuine anomaly: traffic to the original backend had dropped as expected when the failover was triggered, but the corresponding increase in traffic to the new backend did not fully materialize. This discrepancy prompted an immediate investigation. Internal service alerts for pending jobs, Document Understanding test failures, and Automation Solutions timeouts also fired during this period, corroborating the customer impact. We confirmed at 15:25 UTC that Orchestrator was receiving "not found" errors when attempting to reach the messaging component. ## Response * **14:07 UTC** — A configuration change to trigger the on-demand failover was merged. * **14:15 UTC** — Orchestrator began receiving "not found" errors when connecting to the messaging component. * **14:52 UTC** — Our messaging team detected a traffic anomaly and began investigating. * **15:03 UTC** — A change to revert the failover was prepared. * **15:10 UTC** — The revert was merged; however, the configuration-propagation automation did not run due to an ongoing GitHub incident. * **15:20 UTC** — GitHub publicly reported its incident, confirming why our configuration changes were not propagating. * **15:25 UTC** — We confirmed the impact to Orchestrator and engaged the team responsible for configuration propagation. * **16:35 UTC** — The corrective configuration propagated to the affected clusters once GitHub recovered; errors stopped and service was restored. Events that were not delivered during the impact window were replayed. ## Follow-Up We are implementing the following improvements: 1. **Improved alerting in Orchestrator** to detect and surface errors from internal messaging endpoints more quickly, reducing the time to detection. 2. **Pre-change verification** to confirm that new backend configuration has fully reached all clusters before a traffic switch is initiated. 3. **Reducing our dependence on a single external provider** in the configuration-propagation path, so that corrective changes can still be applied when an upstream provider is degraded.

From 10 June 2026, 11:00 AM UTC to 2:20 PM UTC, Serverless Robots in the US region experienced intermittent latency due to temporary resource constraints. The issue was identified and mitigated by the engineering team, and service performance has since returned to normal.

On 3rd June 2026, between 00:16 UTC and 02:17 UTC, customers in the Japan region may have experienced intermittent slowness while accessing the UiPath Platform. During a brief window near the end of this period — approximately 02:15 UTC to 02:17 UTC — the impact was more severe: a large majority of requests to the region failed for roughly two minutes before service automatically recovered. The issue has since been mitigated, and all services have returned to normal operation. A detailed Root Cause Analysis will be shared separately.

## Customer impact Between June 3, 2026 at 12:30 am UTC and 2:22 am UTC, a subset of customers in the Japan region experienced increased latency and intermittent errors across the **UiPath Commercial Cloud**, most visibly in **Orchestrator**, **Studio Web**, and **Access Policy \(IP Restrictions\)** functionality. The impact lasted approximately 1 hour and 52 minutes. Service performance returned to normal once the underlying infrastructure issue was resolved. ## Root cause The incident was caused by an infrastructure issue within Microsoft Azure API Management in the Japan region. An underlying platform component experienced a failure that gradually degraded request processing and caused intermittent connection issues. This resulted in increased latency and errors for affected services. Service recovered automatically once the underlying platform component returned to normal operation. ## Detection The issue was detected through automated monitoring for elevated API gateway error rates on June 3, 2026 at 2:48 am UTC — approximately 32 minutes after the start of the observed customer-impact window. The alert created the incident response channel, and responders acknowledged the alert immediately. ## Response ‌ After the issue was detected, engineers investigated the increase in latency and errors affecting the Japan region. The investigation confirmed that the disruption originated from an underlying infrastructure issue within Azure API Management. Service performance had already returned to normal by the time the investigation began, and monitoring confirmed stable operation throughout the remainder of the incident review. ## Follow up 1. Microsoft has confirmed this was a rare infrastructure event caused by a failed VM restart on the APIM platform, and that no customer-side action was required to prevent or mitigate it. 2. We are evaluating additional regional synthetic availability checks for Japan to improve detection speed for similar short-lived APIM disruptions. 3. We are improving alert enrichment for regional APIM error spikes to include automatic blast-radius identification and faster customer-impact assessment.