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.