UiPath experienced a major incident on May 5, 2026 affecting IXP, lasting 1h 16m. The incident has been resolved; the full update timeline is below.
Affected components
Update timeline
- investigating May 05, 2026, 08:22 AM UTC
We are investigating reports of a regional outage impacting IXP service in US Region Impact: Users are unable to access IXP services in the affected region. Next update: Our teams are investigating the cause.
- monitoring May 05, 2026, 08:35 AM UTC
This issue was limited to a single customer report and the service functioning was not impacted. Next update: We are monitoring closely and will close this incident as soon as we make sure there is no wider impact.
- resolved May 05, 2026, 09:38 AM UTC
This issue was limited to a single customer report and the service functioning was not impacted.
- postmortem May 06, 2026, 01:36 PM UTC
## Customer Impact A single customer tenant in the U.S. region experienced a complete inability to use the IXP service. All requests from the affected tenant failed, preventing users from performing both read and write operations, including document processing and automation workflows. ## Scope The issue was isolated to a single customer tenant in the U.S. region. No other customers or regions were affected, and all other services remained fully operational throughout the incident. ## Root Cause The incident was caused by the revocation of access to a customer-managed encryption key required by the affected tenant. This key secures the storage and retrieval of the tenant's data within the IXP service. When the key became inaccessible, the service could no longer decrypt or process any of the tenant's data, causing all requests to fail. ## Detection The first errors occurred on Sunday, May 4, 2026, but the incident was not detected until May 5, 2026 at 8:15 am UTC, when the customer reported being unable to access IXP. A contributing factor was identified in our error handling: the service returned generic server error responses \(HTTP 500\) instead of more descriptive client error responses \(HTTP 4xx\) when the encryption key was inaccessible. This made it harder for the customer to self-diagnose the issue. ## Response Upon detection, our engineering team assembled on an incident bridge and began reviewing error logs and service metrics. The team concluded with high confidence that key access was revoked on the customer's side, likely as part of a security review or key consolidation activity. Recovery was achieved after the customer was contacted and provided with the specific error details. The customer restored UiPath’s access to the encryption key, allowing IXP to function correctly again. ## Follow-up 1. Review detection of CMEK revocation. 2. Correct error responses. Ensure that under CMEK revocation, customers are presented with a clear error message that indicates the issue and how to resolve it.