UiPath incident

Community Orchestrator degradation

Notice Resolved View vendor source →

UiPath experienced a notice incident on July 20, 2026, lasting —. The incident has been resolved; the full update timeline is below.

Started
Jul 20, 2026, 03:18 PM UTC
Resolved
Jul 20, 2026, 03:18 PM UTC
Duration
—
Detected by Pingoru
Jul 20, 2026, 03:18 PM UTC

Update timeline

  1. resolved Jul 20, 2026, 03:18 PM UTC

    Customers on the UiPath Community plan hosted in the North Europe region may have experienced UiPath Orchestrator service degradation between 14:22 and 14:39 UTC on 20 July 2026. During this period the region's Orchestrator database reached 100% worker utilization, causing a portion of requests to fail or respond slowly until utilization recovered. Client side retries generally succeeded, no data loss occurred, and the issue is now fully resolved.

  2. postmortem Aug 10, 2026, 08:32 AM UTC

    ## Customer impact Between July 20, 2026 at 2:22 pm UTC and July 20, 2026 at 2:39 pm UTC, a subset of some users of UiPath Orchestrator in Europe region experienced service degradation lasting approximately 17 minutes. During this window, some Orchestrator requests failed or responded slowly. Automatic retries from client applications generally succeeded, and no data was lost. ## Root cause During a scheduled Orchestrator deployment, a required database preparation step had not been effectively applied in Europe region. This preparation step was designed to make a subsequent database change safe and non-disruptive. Because it was missing, the deployment triggered a blocking database change on a heavily used table during peak traffic. This blocking operation prevented other database queries from completing, which exhausted available database processing capacity and caused Orchestrator requests to fail or slow down until the operation completed and capacity recovered. ## Detection Automated alerting detected the elevated failure rate at 2:30 pm UTC on July 20, 2026, approximately 8 minutes after impact began. ## Response Our engineering team began investigating the elevated failure rate as the automated alerts came in. A formal incident response channel was opened at 2:53 pm UTC and, within one minute, the team confirmed that the service had already recovered and that customers had been affected. At 3:10 pm UTC, we drafted a customer-facing impact summary confirming the degradation window of 2:22 pm to 2:39 pm UTC, intermittent request failures, successful retries in most cases, and no data loss. At 3:18 pm UTC, we updated the public status page to reflect the incident as resolved. We closed the incident at 3:35 pm UTC. ## Follow up 1. Reapply the required database preparation step using the safe, non-blocking method before resuming the deployment in the affected environment. 2. Add validation to our deployment process so that prerequisite steps are independently confirmed as completed in the target environment before a deployment proceeds — rather than relying solely on task-tracking status.