UiPath incident

Uipath in Switzerland Region is facing Outage

Notice Resolved View vendor source →

UiPath experienced a notice incident on May 13, 2026 affecting Automation Cloud, lasting 21m. The incident has been resolved; the full update timeline is below.

Started
May 13, 2026, 02:04 PM UTC
Resolved
May 13, 2026, 02:25 PM UTC
Duration
21m
Detected by Pingoru
May 13, 2026, 02:04 PM UTC

Affected components

Automation Cloud

Update timeline

  1. identified May 13, 2026, 02:04 PM UTC

    We have identified the cause of the regional outage impacting UiPath services in Switzerland and restoration efforts are underway. Impact: Services remain unavailable in the affected region. Next update: Our teams are actively working to restore service.

  2. monitoring May 13, 2026, 02:16 PM UTC

    Services are recovering across the affected region following mitigation impacting UiPath Cloud services in Switzerland. Impact: Users may experience intermittent availability during recovery. Next update: Monitoring continues.

  3. resolved May 13, 2026, 02:25 PM UTC

    This incident has been resolved and the region is fully operational. Impact: Users should no longer experience issues.

  4. postmortem May 18, 2026, 05:47 AM UTC

    ## Customer impact Between May 13, 2026, 1:50 pm UTC and 2:25 pm UTC, customers using Automation Cloud services in our Switzerland region experienced service unavailability. Failures in the licensing service prevented licensing checks from completing, which in turn made parts of Automation Cloud inaccessible. Impact was limited to the Switzerland region and lasted approximately 35 minutes. Services began recovering at 2:16 pm UTC, with full resolution confirmed at 2:25 pm UTC. ## Root cause The issue was caused by a deployment configuration change in the licensing service that did not apply cleanly. The change was part of a planned resource rename intended to streamline future licensing deployments. A prior deployment earlier that week did not complete successfully, leaving the rename in an intermediate state with no immediate warning that something was wrong. The current deployment in the affected environment still references the old resource name. At the start of the incident, the licensing service needed to access the resource, which caused dependent service calls to fail and surfaced to customers as service unavailability. ## Detection Automated monitoring detected the issue at 1:50 pm UTC when multiple health checks for licensing-dependent workflows in Switzerland failed simultaneously. The incident was declared immediately upon alert firing, with no measurable gap between detection and declaration. An initial investigation quickly localized the failure to the regional licensing service rather than its dependents. ## Response The incident was opened at 1:50 pm UTC and responders joined the incident’s bridge immediately. By 2:04 pm UTC, the team had identified the cause, prepared mitigation steps, and updated the public status page to indicate that restoration work was underway. Mitigation involved correcting the deployment configuration in the affected environment and retrying the deployment. Health checks began recovering shortly after, and service recovery was confirmed at approximately 2:12 pm UTC while the deployment continued to roll out across the region. At 2:16 pm UTC, the incident was marked as mitigated and the status page moved to monitoring. At 2:25 pm UTC, the deployment completed successfully and the incident was marked as resolved. ## Follow-up We are evaluating preventive measures to ensure that incomplete deployments do not leave services in an inconsistent configuration state. The team is prioritizing improvements to deployment validation and to the detection of configuration drift between environments, so that mismatches like this are caught before they reach production traffic.