Degraded Login Performance in the United States Region

Update timeline

1. investigating Jun 11, 2026, 10:43 PM UTC

   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.

2. monitoring Jun 11, 2026, 11:38 PM UTC

   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.

3. resolved Jun 11, 2026, 11:49 PM UTC

   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.

4. postmortem Jun 23, 2026, 05:27 AM UTC

   ## Customer impact Between June 11, 2026 at 10:26 pm UTC and June 11, 2026 at 11:49 pm UTC, a subset of customers in the U.S. region experienced degraded sign in functionality. Users may have had trouble signing in to Orchestrator, the UiPath identity portal, and most of the other UIPath platform services. The total duration from incident start to resolution was one hour and 23 minutes. ## Root cause Compute instances serving an internal service used during sign in flows began repeatedly restarting. During startup, the service attempts to establish connections to a Redis cache dependency. Under elevated Redis load, these connection attempts stalled, causing the application to become unresponsive. Health checks then failed, triggering restarts—which repeated the cycle and progressively reduced healthy serving capacity. Contributing factor: the regional Redis instance was consistently running at near-full memory utilization during work hours, with key count steadily growing. This degraded Redis responsiveness and made connection attempts more likely to fail. ## Detection The issue was detected through automated alerting at 10:26 pm UTC on June 11, 2026. There was no measurable gap between incident start and detection. A public investigation update was posted at 10:43 pm UTC. ## Response At 10:29 pm UTC, our engineering team began investigating application telemetry data. By 10:35 pm UTC, service logs confirmed that the affected instances were starting up successfully but then terminating shortly afterward, consistent with the observed restart behavior. The team mitigated the issue by doubling the minimum number of running instances for the affected service in the impacted environment. This ensured lower load on each instace which allowed instances to serve their allocated traffic without relying on slow redis connectivity. The instances stopped restarting, recovered and eventually succeeded in establishing their connections. Full recovery was confirmed at 11:49 pm UTC. ## Follow-up 1. Improve service resilience to cache connectivity issues 2. Address Redis capacity 3. Add Redis capacity alerting