Multiple services impacted in Korea and Japan due to cloud service provider issue

Update timeline

1. resolved Sep 10, 2026, 03:40 PM UTC

   Issue is mitigated now. Cloudflare had DNS update delays during this time briefly for 9 minutes. Multiple Services were impacted due to this in Korea and Japan causing 520 errors. Incident link: https://www.cloudflarestatus.com/incidents/nhfcmzd1pv4p

2. postmortem Sep 24, 2026, 01:27 PM UTC

   ## Customer impact Between 2:34 pm UTC and 2:43 pm UTC on September 10, 2026, customers in Japan and Korea experienced failures when accessing multiple UiPath Automation Cloud services. Affected requests returned HTTP 520 errors. The impact lasted approximately nine minutes and affected Orchestrator, Apps, authentication, and other platform services in the region. ## Root cause Our upstream cloud service provider performed unplanned maintenance, which resulted in a decreased availability of resources which UiPath Automation Cloud relies on. Once the maintenance completed, services recovered almost immediately. ## Detection Our engineering team detected the issue through automated service monitoring and began investigating at 3:18 pm UTC on September 10, 2026. This was 44 minutes after impact began and 35 minutes after the affected window had already ended. By the time our team reviewed monitoring data, the failures had stopped and services had recovered. ## Response At 3:19 pm UTC, the incident was classified as customer-impacting and presumed to be correlated to an active incident at our DNS provider. By 3:31 pm UTC, our team confirmed that HTTP 520 errors were being returned for traffic originated from Japan and Korea. Further investigation pointed that the root cause of the issue was not at the DNS layer but at our routing infrastructure layer. A support case was opened with the cloud service provider, which confirmed the root cause as being unplanned maintenance on their part. At 3:35 pm UTC, a customer status page update was initiated. At 3:40 pm UTC, the status page update was published documenting the nine-minute impact window and attributing the cause to a third-party DNS delay. The incident was marked resolved at 3:41 pm UTC after monitoring confirmed no continuing failures. ## Follow up 1. We are evaluating follow-up actions based on this event and similar past incidents involving cloud infrastructure and network behavior, including improvements to reduce the time between the start of an externally caused outage and our team's awareness of it as well as increasing the capacity of our routing layer to make it more resilient.