Multiple Regions - Studio Web - Studio Web Disruption

Update timeline

1. resolved Mar 10, 2026, 06:20 PM UTC

   On March 10, 2026, between 16:16 and 16:36 UTC, some customers experienced difficulty accessing Studio Web. During this period, our monitoring systems detected that the service was temporarily unavailable. Our investigation shows that a routine deployment activity occurred around the same time and the service also experienced a short failover event. These combined conditions contributed to a brief interruption in availability. The service recovered automatically within minutes, and access to Studio Web was fully restored without manual intervention. Impact Customers may have experienced temporary inability to access Studio Web during the time window above. Current Status The service is operating normally.

2. postmortem Apr 17, 2026, 08:48 AM UTC

   ## Customer Impact On March 10, 2026, between 16:16 and 16:36 UTC, a small subset of customers in the Europe region were unable to access Studio Web. During this approximately 20-minute window, attempts to load Studio Web returned errors or routed users to a service-unavailable page. Some customers experienced a longer perceived outage — up to roughly 45 minutes — because the service-unavailable page did not automatically recover once the service was restored. The impact was limited to Studio Web for a small subset of customers in the Europe region. Other UiPath services and regions were not affected. ## Root Cause A routine deployment introduced a security hardening update that changed the internal network port Studio Web listens on, along with how our internal routing layer forwards traffic to Studio Web's service components. During our staged deployment process, the routing update was applied while some service instances were still running the previous configuration. The resulting mismatch caused production traffic to be sent to a pathway that was no longer accepting connections, producing service-unavailable errors. A compounding factor was infrastructure capacity pressure in the shared production environment at the time of the deployment, which delayed the provisioning of replacement service instances and extended the recovery window. ## Detection The incident was detected within approximately 3 minutes of onset through our automated monitoring, which continuously checks Studio Web availability from multiple geographic locations. A subsequent alert confirmed that an automatic failover to our secondary environment had been triggered. The on-call engineering team engaged within 5 minutes of the first alert and correlated the disruption with the in-progress deployment. ## Response Upon detection, the on-call team verified that the deployment was progressing through its staged rollout and determined that it would self-recover as new service instances came online. No manual rollback was required. The service recovered automatically within minutes, and access to Studio Web was fully restored without manual intervention by 16:36 UTC. Customers who had been routed to the service-unavailable page were advised to reload Studio Web to regain access. ## Follow-Up To prevent similar incidents and reduce customer-facing impact from comparable conditions, we are implementing the following improvements: 1. We have updated our deployment configuration so that internal service routing changes are coordinated with service instance updates, preventing the specific mismatch that caused this incident. 2. We have tuned our deployment infrastructure chart to avoid service instance starvation when the shared cluster is under memory pressure, so that rollouts proceed reliably even under capacity constraints. 3. We are adding auto-recovery to the service-unavailable page so that when Studio Web is restored, the page redirects customers back to the application automatically rather than requiring a manual reload. 4. We have investigated and addressed a limitation in our automatic failover that caused only a small fraction of production traffic to route to the secondary environment during the outage. Failover is now configured to fully mitigate similar primary-environment disruptions in the future.