UiPath Outage History

Started Jul 02, 2026, 09:15 PM UTC· resolved Jul 03, 2026, 01:49 AM UTC

1. identified Jul 02, 2026, 09:15 PM UTC

   We are currently seeing some instance executions become stuck due to elevated error rates following a recent deployment. The root cause has been identified, and our team is actively working to resolve the issue.

2. identified Jul 02, 2026, 11:09 PM UTC

   A fix has been identified and we are working on deploying it. Please note that only instances where instance management operations were performed (Pause, resume, retry, goto, migrate, cancel, patchvariable) were impacted.

3. resolved Jul 03, 2026, 01:49 AM UTC

   A fix has been deployed to all impacted regions.

4. postmortem Jul 23, 2026, 01:39 PM UTC

   ## Customer impact Between **July 2, 2026 at around 20:57 UTC and July 3, 2026 around 01:01 am UTC**, some **Maestro workflows** in **Australia and U.S. regions** using instance-level operations like Retry, Pause, Resume, Cancel, Migrate, and patch variables were potentially impacted, with workflows appearing to be stuck state. ## Root cause Maestro workflows keep a detailed record of every step they execute, and rely on this record to resume a workflow from where it left off. A recent change introduced inconsistencies into this record for some workflows. As a result, those workflows could not resume and appeared to be stuck. ## Detection The incident was caught on an internal report. While we had alerts in place, the rate of errors was not enough to trigger the alerts. ## Response A cross-team bridge was set up on July 2, 8.57 pm UTC, and engineering started looking into the errors being thrown from workflows from Telemetry. Soon enough, on an analysis of telemetry and commits that were included as a part of the latest release payload, the root cause was identified. Once that was done, a hotfix was developed and validated to confirm that it addressed the issue. The issue was mitigated once the hotfix was deployed to all affected rings and affected customer workflows were retried to ensure they were running. ## Follow-up We are implementing enhanced monitoring and alerting to detect such issues before they affects customers and implementing guardrails to ensure that these issues do not make it into production code.

Read the full incident report →

Started Jul 02, 2026, 05:24 PM UTC· resolved Jul 02, 2026, 07:02 PM UTC

1. investigating Jul 02, 2026, 05:24 PM UTC

   We are currently observing a partial outage on IXP and team is investigating this issue.

2. monitoring Jul 02, 2026, 06:21 PM UTC

   The issue has been mitigated and we are now monitoring the service currently. Please note that some functionality might take some time to recover as it catches up.

3. resolved Jul 02, 2026, 07:02 PM UTC

   The issue has been resolved and we are actively monitoring the service.

4. postmortem Jul 28, 2026, 09:47 AM UTC

   ## Customer impact Between **July 2, 2026 at 5:17 pm UTC and July 2, 2026 at 7:03 pm UTC,** a subset of customers experienced a **partial outage of the IXP service in U.S. region**. Parts of IXP functionality were unavailable or delayed, and after mitigation, some functionality needed additional time to recover as processing caught up. The impact was limited to a small subset of customers in the U.S. region using the affected IXP service. Both Communications Mining and Unstructured and Complex Documents capabilities of IXP were affected. The total incident duration was 1 hour and 46 minutes. ## Root cause A preemptive increase in memory allocation for the service to account for planned increased usage was done incorrectly, causing services to compete for memory, pushing critical services out of the stack. One of those services was the network mesh layer, which resulted in multiple internal services being unable to talk to each other. To restore service health, we re-adjusted memory allocation settings to correctly load-balance the system and avoid memory competition. After those changes, the service stabilized. ## Detection The issue was detected as we were monitoring the planned scale-up of the region. On July 2, 2026 at 5:16 pm UTC, and incident was created as we noticed internal service outages. The incident was declared customer-impacting at 5:17 pm UTC. ## Response At 5:24 pm UTC on July 2, 2026, we published a public status update stating that we were investigating a partial outage of IXP. In the meantime, we investigated the failing services and initially thought the cause was low capacity in the underlying infrastructure. Once the failure was isolated to the network mesh, infrastructure, theory was dismissed and resolution followed. At 5:50 pm UTC, we applied a configuration update to increase the memory available to the network mesh at the affected services. At 6:16 pm UTC, service health had improved enough to inform our customers on Status page, and at 6:21 pm UTC the incident was marked mitigated with a public update noting that some functionality might take time to recover as it caught up. At 6:47 pm UTC, we confirmed that the service was stable. At 7:02 pm UTC, we published the resolved status update, and at 7:03 pm UTC the incident was marked resolved. ## Follow-up 1. Persist the memory changes across all regions. 2. A follow up analysis of all memory usage across all services was scheduled to preemptively avoid a similar incident.

Read the full incident report →

Started Jul 01, 2026, 05:29 PM UTC· resolved Jul 01, 2026, 08:07 PM UTC

1. identified Jul 01, 2026, 05:29 PM UTC

   This issue is causing degraded performance impacting maestro instances and team is currently investigating the issue. Impact: Workflows may experience slowness or get stuck.

2. monitoring Jul 01, 2026, 06:46 PM UTC

   The immediate issue has been mitigated. However, because this specific failure mode develops gradually over time, we have additional monitoring in place and collecting more diagnostic data to prevent a recurrence.

3. resolved Jul 01, 2026, 08:07 PM UTC

   The issue remains quiet and has not resurfaced. We are implementing our active monitoring and rapid-response guardrails in place while the engineering team continues investigating the root cause.

4. postmortem Jul 30, 2026, 10:36 AM UTC

   ## **Customer Impact** Between **July 1, 2026 at 17:18 UTC** and **July 1, 2026 at 20:07 UTC**, a subset of customers experienced degraded performance in **Maestro**. During this period, some workflows executed more slowly than expected or became stuck, which may have delayed automation execution. The issue affected **Maestro instances in the EU region**. Service was fully restored after mitigation was applied, and workflow processing returned to normal. ## **Root Cause** The incident was caused by memory exhaustion in the Maestro workflow processing service. A small number of workflow executions encountered errors that caused them to repeatedly retry instead of stopping. As these executions remained active, they consumed increasing worker resources until some worker instances exhausted available memory and restarted, resulting in degraded workflow processing. The immediate mitigation increased the memory available to the affected worker service, restoring normal operation. Engineering is implementing additional safeguards to ensure workflows encountering non-recoverable failures stop after a defined number of retries and cannot consume unbounded service resources. ## **Detection** The issue was detected through automated monitoring at **17:18 UTC** on **July 1, 2026**, which immediately triggered incident creation. Follow-up investigation and log analysis confirmed that the affected workflow worker service was experiencing out-of-memory errors. ## **Response** Following detection, engineering began investigating the degraded workflow processing and identified memory exhaustion within the workflow worker service as the source of the issue. Customers were notified through the public status page while the investigation was in progress. Engineering increased the memory allocation for affected worker services in the EU region, restoring normal service behavior. Affected workflow instances were reset where necessary to allow processing to resume. Following a period of monitoring that confirmed stable operation and no recurrence of the issue, the incident was resolved. ## **Follow-Up** To help prevent similar incidents, we are implementing the following improvements: 1. **Workflow retry safeguards:** Implement product improvements to ensure workflows that encounter non-recoverable failures stop after a defined number of retries and cannot consume unbounded worker resources. 2. **Increase worker capacity:** Increase memory allocation for the Maestro workflow worker service in both the EU and U.S. regions to reduce the likelihood of recurrence from the same memory exhaustion pattern. 3. **Enhanced monitoring:** Maintain additional monitoring and diagnostic data collection for this failure mode so that gradually developing memory pressure can be identified earlier.

Read the full incident report →

Started Jul 01, 2026, 03:50 PM UTC· resolved Jul 01, 2026, 08:01 PM UTC

1. investigating Jul 01, 2026, 03:50 PM UTC

   Increased latency and degraded performance in US, Investigation is in progress.

2. investigating Jul 01, 2026, 03:57 PM UTC

   Increased latency and degraded performance in US, Investigation is in progress.

3. monitoring Jul 01, 2026, 04:02 PM UTC

   Mitigation has been applied and performance is improving for the issue that impacted [impacted functionality / user symptom] in [Service] across [Region]. Impact: Users may still experience [remaining symptom], but this should continue to improve. We are monitoring closely to ensure stability.

4. monitoring Jul 01, 2026, 04:10 PM UTC

   Mitigation has been applied and performance is improving for the issue that impacted Orchestrator in US. Impact: Users may still experience degraded performance, but this should continue to improve. We are monitoring closely to ensure stability.

5. monitoring Jul 01, 2026, 05:31 PM UTC

   Performance has continued to improve for the issue impacting Orchestrator in the US, and latency has decreased. Impact: Some users may still experience intermittent degraded performance while we continue to investigate. We are monitoring closely to ensure stability.

6. monitoring Jul 01, 2026, 06:58 PM UTC

   The issue has been mitigated and Orchestrator performance has returned to expected levels after degraded performance impacted US. Impact: No ongoing user impact.

7. resolved Jul 01, 2026, 08:01 PM UTC

   The regional outage has been resolved and all services in US are fully operational. Impact: No ongoing user impact.

8. postmortem Jul 24, 2026, 10:18 AM UTC

   ## Customer impact Between **July 1, 2026 at 3:38 pm UTC and July 1, 2026 at 6:58 pm UTC**, a subset of customers experienced increased latency and degraded performance when using Orchestrator in **U.S. region**. Some requests may have timed out during this period. The customer-impacting period lasted about 40 minutes. ## Root cause During a routine service update, a frequently-used database query was improved for better performance. The update to the query was correct; however, it caused the database to generate a new execution plan for that query. This new plan was built using a non-representative dataset, so it was not well-suited to production-scale data. As a result, the query began executing inefficiently, which drove a sustained increase in database CPU. The elevated CPU led to the query timeouts, increased request latency, and job execution delays that customers experienced during the incident. ## Detection The issue was detected through an automated availability alert at July 1, 2026 at 3:23 pm UTC. A customer-impacting incident was declared on July 1, 2026 at 3:39 pm UTC. ## Response By July 1, 2026 at 3:39 pm UTC, the affected Orchestrator database was identified as needing additional capacity. At 3:41 pm UTC, the decision was made to scale the database and update the public status page to indicate degraded performance and possible timeouts. The first public status page update was posted at 3:50 pm UTC, noting increased latency and degraded performance for Orchestrator in the U.S. region. By 3:59 pm UTC, the database scaling had completed and latency was confirmed to have returned to normal. At 4:02 pm UTC, the incident was marked as mitigated. A monitoring update was posted to the public status page at 4:10 pm UTC, confirming that mitigation had been applied and performance was improving, while noting that users might still experience some degraded performance. Monitoring continued after mitigation. The incident was formally resolved at 8:01 pm UTC. ## Follow-up * Activating query changes independently of deployment, so execution plans are generated against representative production data. * Tooling to detect and clear inefficient execution plans automatically, so the database can regenerate a better one. * Monitoring to flag when a single query consumes a disproportionate share of database CPU, so we can act before performance is affected.

Read the full incident report →

Started Jun 30, 2026, 08:10 PM UTC· resolved Jun 30, 2026, 11:17 PM UTC

1. identified Jun 30, 2026, 08:10 PM UTC

   We have identified the cause of the degraded performance impacting the GetJobs Activity for Orchestrator in Europe, Switzerland, Canada, India, Australia and UAE. We are actively working on a mitigation, which will be applied shortly Additional updates will be provided as we move toward resolution.

2. identified Jun 30, 2026, 09:30 PM UTC

   We have a mitigation available, and are beginning to roll it out to affected regions. We will provide more updates as the mitigation takes effect

3. monitoring Jun 30, 2026, 10:44 PM UTC

   The mitigation is taking effect, and we are seeing performance return to normal

4. monitoring Jun 30, 2026, 10:48 PM UTC

   The mitigation is taking effect, and we are seeing performance return to normal

5. monitoring Jun 30, 2026, 10:59 PM UTC

   All regions have recovered, we will monitor to ensure stability

6. resolved Jun 30, 2026, 11:17 PM UTC

   The incident has been resolved.

7. postmortem Jul 15, 2026, 10:51 AM UTC

   ## Customer Impact Beginning on **June 29, 2026 at 4:00 pm UTC and continuing until June 30, 2026 at 10:59 pm UTC**, customers across six regions—Europe, Switzerland, Canada, India, Australia, and the UAE, experienced failures when using the Get Jobs activity in Orchestrator. Affected automations returned the error: "**Could not find a property named 'Environment' on type SimpleReleaseDto.**" The total customer-facing impact duration was approximately 31 hours, with the earliest affected region impacted for more than 24 hours before the issue was identified. Automations that depended on this activity failed when attempting to retrieve job information. ## Root Cause As part of the announced deprecations related to robots and environments, a corresponding server-side change was made that stopped accepting requests in the legacy format. Multiple already-released versions of the _Get Jobs_ activity were still sending requests using that deprecated format specifically including the `Environment` property. As a result, the server rejected those requests, causing the activity to fail across all affected versions. ## Detection The issue was detected through a customer-impacting alert on June 30, 2026 at 7:49 pm UTC. At 8:40 pm UTC, a log review showed that one affected region \(Australia\) had already been impacted for more than 24 hours, while Canada and India were in their first hours of impact. The issue was introduced with a hotfix deployed in Europe region on June 25 and subsequently propagated to Switzerland, Canada, India, Australia, and the UAE between June 29 and June 30. ## Response On June 30, 2026 at 7:58 pm UTC, a server-side fix was identified for deployment. At 8:03 pm UTC, the engineering team determined the scope of degradation for customers using the Get Jobs activity and recommended updating our public status page. At 8:10 pm UTC, the status page was updated to indicate that the cause had been identified and that mitigation work was underway. The mitigation was a server-side compatibility fix that restored acceptance of the deprecated request format used by existing Get Jobs activity versions. Deployment began on June 30, 2026 at 9:10 pm UTC. By 10:22 pm UTC, successful requests were observed in the first recovered regions, and by 10:44 pm UTC the incident was marked mitigated as performance was returning to normal. Deployment completed across all affected regions on June 30, 2026 at 10:54 pm UTC. At 10:59 pm UTC, all regions were confirmed to have recovered and the public status page moved to monitoring. The incident was marked resolved on June 30, 2026 at 11:17 pm UTC. ## Follow-up 1. We added automated regression tests to validate compatibility for older Get Jobs request formats before similar server-side changes are released, preventing this category of regression in future updates. 2. We are adding a deprecation alert that will capture similar cases in the future.

Read the full incident report →

Started Jun 28, 2026, 04:38 PM UTC· resolved Jun 28, 2026, 05:59 PM UTC

1. investigating Jun 28, 2026, 04:38 PM UTC

   Increased latency affecting Maestro workflow executions in the North Europe

2. monitoring Jun 28, 2026, 05:35 PM UTC

   We have applied a mitigation and seeing significant performance improvements in Maestro workflow executions. We will continue to monitor to ensure the situation has stabilized.

3. resolved Jun 28, 2026, 05:59 PM UTC

   The issue has been resolved. The mitigation has been effective, and Maestro workflow executions have returned to normal.

4. postmortem Jul 08, 2026, 02:36 PM UTC

   # External RCA: Delays in Maestro Workflow Execution \(Europe\) **Incident date:** June 28, 2026 · **Impact window:** 16:00–18:00 UTC \(2 hours\) · **Status:** Resolved ## Customer impact On June 28, 2026, between 16:00 and 18:00 UTC, a subset of customers using UiPath Maestro experienced increased latency in workflow executions. This included delays in the start of execution of Maestro instances, and slower task execution generally. The impact was concentrated in the Europe region, and the total customer-impact duration was approximately two hours. As a precaution, capacity adjustments were also applied in the US region. All times are in UTC. ## Root cause Maestro's workflow execution relies on an underlying workflow orchestration platform made up of multiple components — components that process and execute workflow tasks, and a central component that coordinates and dispatches that work between them. In response to an earlier, unrelated load issue, the capacity of the task-processing components had been increased to handle higher demand. The capacity of the central coordinating component, however, was not increased in proportion. As the additional task-processing capacity came online, it generated more concurrent requests to the coordinating component than that was configured to accept. Once its concurrency limit was reached, the latter began rejecting \(rate-limiting\) a portion of the incoming task-polling requests. When these requests were rejected, the system repeatedly retried, which triggered further rate-limiting, and slowed the overall pace of Maestro workflow execution. ## Detection The incident was detected from an internal report from of the UiPath internal teams. An incident bridge was started at 16:00 UTC. A public status update was posted at 16:39 UTC, notifying customers of increased latency affecting Maestro workflow executions in Europe. ## Response Immediately after detection, engineering began investigating. By 17:05 UTC, the team had identified the underlying cause as the workflow orchestration service's concurrency limit being exceeded. Mitigation was applied by increasing the capacity of the workflow execution and orchestration components in Europe. Performance improved significantly following the change, and the status page was updated to **monitoring** at 17:35 UTC. After confirming stability, the incident was marked as **resolved** at 18:00 UTC, with Maestro workflow executions returning to normal. ## Follow-up 1. **Capacity validation through load testing**: Run focused load testing to establish the correct orchestration concurrency limits and capacity settings for Maestro under realistic production demand, so these limits are validated ahead of time rather than tuned during an incident. 2. **Targeted alerting**: Add earlier, more direct alerting on orchestration concurrency saturation and Maestro workflow-execution latency, so similar conditions are caught before they reach customer impact.

Read the full incident report →

Started Jun 25, 2026, 02:06 PM UTC· resolved Jun 25, 2026, 02:06 PM UTC

1. resolved Jun 25, 2026, 02:46 PM UTC

   The Orchestrator service in the East US region experienced increased latency and a subset of failed requests between June 25, 14:06 UTC and June 25, 14:12 UTC. During this period, customers may have encountered slower response times and intermittent request failures. The issue has been mitigated, and the service is now operating normally. We are continuing to review the incident and publish the root cause. Affected Services: East US – Orchestrator

2. postmortem Jul 30, 2026, 07:34 AM UTC

   ## Customer Impact Between June 25, 2026 at 2:06 pm UTC and June 25, 2026 at 2:12 pm UTC, Orchestrator in the US region experienced increased latency and a subset of failed requests. During this six-minute window, customers may have seen slower Orchestrator response times and intermittent request failures. The impact was limited to customers using Orchestrator in the US region. Existing connections and overall database availability were not affected, and no data was lost. ## Root Cause The disruption was caused by an internal maintenance operation, which made a brief configuration change to the database - a change that momentarily acquires a lock normally released in a predictable short time. On this occasion the operation was interrupted before completing, so the lock was not released on schedule and stayed in place for several minutes until the database's automatic cleanup released it. While the lock was held, the database remained online and existing connections continued to work; only the establishing of new database connections was blocked, which produced the increased latency and failed requests during the window. ## Detection The issue was identified through automated monitoring for Orchestrator in the US region, which began alerting within approximately two minutes of the impact. Our formal incident response process was initiated on June 25, 2026 at 2:24 pm UTC; by that point the customer-impacting window had already ended and the service had recovered. ## Response At 2:24 pm UTC on June 25, 2026, our incident response process was activated and responders were engaged. Initial investigation examined the network and API management layers and considered a possible platform-level database event; both were ruled out as the cause. At 2:33 pm UTC, service monitoring confirmed the customer-impacting window as 2:06 pm UTC to 2:12 pm UTC in the US region. A status page update was requested at 2:33 pm UTC and published at 2:46 pm UTC with the confirmed impact window and affected service. Because the service had already returned to normal operation at 2:12 pm UTC, the incident was marked resolved at 2:46 pm UTC. The confirmed root cause was established subsequently through detailed investigation with our cloud database provider. ## Follow Up Root cause has been confirmed and we are taking the following actions to prevent recurrence and reduce the impact of similar events: * Hardening the internal maintenance tooling so an interrupted operation always releases its resources cleanly, even if stopped midway. * Tightening the controls governing how and when such maintenance operations run against production. * Improving monitoring to detect this lock/connection condition earlier.

Read the full incident report →

Started Jun 24, 2026, 09:43 PM UTC· resolved Jun 25, 2026, 12:06 AM UTC

1. monitoring Jun 24, 2026, 09:43 PM UTC

   We observed increased latency affecting Maestro workflow executions in the Europe region between June 12, 2026, 20:00 UTC and June 24, 2026, 15:00 UTC. Impact: Some Maestro workflows experienced slower-than-normal execution times during this period. No other services were impacted. The issue was isolated to Maestro workflow execution in the Europe region. Our team has taken corrective actions to restore normal performance and continues to monitor the service to ensure stability. We apologize for any inconvenience this may have caused.

2. resolved Jun 25, 2026, 12:06 AM UTC

   We observed increased latency affecting Maestro workflow executions in the Europe region between June 12, 2026, 20:00 UTC and June 24, 2026, 15:00 UTC. Impact: Some Maestro workflows experienced slower-than-normal execution times during this period. No other services were impacted. The issue was isolated to Maestro workflow execution in the Europe region. Our team has taken corrective actions to restore normal performance and continues to monitor the service to ensure stability. We apologize for any inconvenience this may have caused.

3. postmortem Jul 22, 2026, 10:10 PM UTC

   ## _Customer Impact_ Between June 12, 2026 at 20:00 UTC and June 24, 2026 at 15:00 UTC, some customers running Maestro workflows in the Europe region experienced slower-than-normal execution times. Individual workflow steps that normally complete within seconds occasionally took significantly longer to start, which slowed overall workflow execution. All affected workflows completed successfully. No workflows failed because of this issue, and no data was lost. ## _Root Cause_ A recent platform update introduced a performance bottleneck in an internal workload-management mechanism used during Maestro workflow execution. **What went wrong:** During periods of high traffic, the mechanism created resource contention on some of the servers that execute workflow steps. This delayed some workflow steps before they started, although the steps ran normally once execution began. **What should have happened:** Internal workload-management operations should not delay workflow execution, including during periods of high traffic. ## _Detection_ The issue was not detected by internal monitoring or alerting. It was reported by a customer on June 22, 2026, and escalated through our incident-management process on June 24, 2026. The investigation confirmed increased Maestro workflow execution latency in the Europe region. ## _Response_ Once the incident was declared, the response team identified the recent platform change responsible for the delays and applied a mitigation across the affected environments. Workflow execution latency returned to normal within the hour, and monitoring confirmed that performance remained stable. ## _Follow-Up_ To reduce the likelihood and impact of similar incidents, we are: * Strengthening performance safeguards for changes that affect workflow execution. * Enhancing monitoring and alerting for unusual increases in workflow execution latency. * Improving rollout and validation controls for performance-sensitive platform changes.

Read the full incident report →

Started Jun 24, 2026, 01:30 PM UTC· resolved Jun 24, 2026, 01:30 PM UTC

1. resolved Jun 24, 2026, 07:24 PM UTC

   We are investigating an issue causing increased workflow execution times for some Maestro workflows in the East US region. Impact Window: June 24, 2026, from 6:38 AM PST to 9:46 AM PST During this period, a subset of workflow executions may experience higher-than-normal latency. We are actively monitoring the situation and working to mitigate the impact. Currently the system is stable and operation and we will provide more information as it becomes available

2. postmortem Aug 14, 2026, 06:29 AM UTC

   ## Customer Impact Between 14:03 and 21:26 UTC on June 18, 2026, and between 17:02 and 23:59 UTC on June 23, 2026, a subset of customers in the U.S. Region, using Maestro and Agent executions—including Conversational Agents and some previously deployed Autonomous Agents—experienced performance degradation and workflows getting stuck in pending state. The two events, a week apart, shared the same underlying root cause. In each case, new workflow operations were stabilized before all pending workflows were fully recovered. During these windows, affected workflows could experience higher-than-normal latency, fail intermittently, or remain stuck in a pending state until recovery processing completed. This RCA covers two related incidents in the U.S. Region that were subsequently determined to stem from the same root cause: an initial event on June 18, 2026 and a recurrence on June 23, 2026. ## Root Cause The incident was caused by our workflow execution backend exhausting its configured memory capacity and restarting repeatedly. Those restarts disrupted workflow state processing, causing some workflow executions to experience latency, fail intermittently, or remain pending. The primary driver of memory growth was an experimental multi-cluster \(active/passive\) replication feature for disaster recovery purpose. This feature accumulated large, long-lived workflow-history objects in memory faster than they could be released. Each time a history-processing component exceeded its memory limit and restarted, it had to reload its in-flight work—including the replication workload — which drove memory back over the limit and triggered another restart. This self-reinforcing cycle continued until responders intervened, and it was not fully resolved by the initial mitigation applied on June 18, which is why the condition recurred on June 23. ## Detection Both events were detected quickly through automated monitoring, including synthetic tests that continuously exercise the platform and alerts for pending/stuck workflow tasks. At the time of the incidents, there was no dedicated alerting on the memory saturation and restart behavior of the affected components, which lengthened the time required to identify the true root cause. Public status updates began after customer impact was confirmed. ## Response and Recovery A cross-team engineering bridge was established to investigate and mitigate the incidents. Early mitigation attempts focused on scaling backend infrastructure and restarting the affected history-processing components. These provided limited relief because they did not address the underlying memory-growth mechanism. Once the memory-retention path was pinpointed through diagnostic heap analysis, the incidents were mitigated by two actions: **increasing the memory capacity allocated to the affected history-processing components**, and **disabling the multi-clusters replication feature** that was the main contributor to the memory growth. After these changes, new workflow operations returned to normal and the region's capacity to process workflows was restored. Workflows that had become stuck in a pending state were recovered by the engineering team where possible. A small number of workflows that customers had already canceled were not replayed, and a limited set of Agent executions that had failed during the incident had to be retried manually by customers. Both incidents were marked resolved after all recoverable workflows had been processed successfully. ## Follow-Up To prevent recurrence and improve detection, we are implementing the following: 1. Right-size the memory capacity and limits for the affected components, and add automatic memory-cap safeguards so the components stay within safe bounds under load. 2. Redesign and re-validate the cross-region replication feature—including load testing with replication enabled—before it is re-enabled, so it can support disaster-recovery needs without causing memory pressure. 3. Add repeatable memory-diagnostic collection capability and operational runbooks for the service, so memory analysis and mitigation can be performed quickly during future incidents.

Read the full incident report →

Started Jun 23, 2026, 05:34 PM UTC· resolved Jun 23, 2026, 11:59 PM UTC

1. investigating Jun 23, 2026, 05:34 PM UTC

   We are investigating reports of degraded performance impacting [impacted functionality / user symptom] for [Service] in [Region]. Impact: Users may experience [describe impacted functionality]. Our teams are working to identify the cause and will share more details as the investigation progresses.

2. investigating Jun 23, 2026, 06:20 PM UTC

   We are investigating reports of degraded performance impacting workflows for Maestro in east US. Impact: Users may experience intermittent failures or stuck workflows. Our teams are working to identify the cause and will share more details as the investigation progresses.

3. investigating Jun 23, 2026, 06:23 PM UTC

   We are investigating reports of degraded performance impacting workflows for Maestro in east US. Impact: Users may experience intermittent failures or stuck workflows. Our teams are working to identify the cause and will share more details as the investigation progresses.

4. investigating Jun 23, 2026, 08:12 PM UTC

   We have scaled up and applied a fix and are seeing positive trends. We will continue to investigate and monitor

5. investigating Jun 23, 2026, 08:44 PM UTC

   Recovery in TaaS East US began at approximately 12:45 PM PST. The service is currently stable, and we will continue monitoring to ensure sustained recovery.

6. monitoring Jun 23, 2026, 10:29 PM UTC

   Operations have been stabilized for new workflows. We are now actively working through workflows that became pending as a result of the incident.

7. resolved Jun 23, 2026, 11:59 PM UTC

   The issue has been fully resolved, and all operations are now functioning normally. All affected workflows have been processed successfully

8. postmortem Jul 09, 2026, 10:10 PM UTC

   ## Customer Impact Between 14:03 and 21:26 UTC on June 18, 2026, and between 17:02 and 23:59 UTC on June 23, 2026, a subset of customers in the U.S. Region, using Maestro and Agent executions—including Conversational Agents and some previously deployed Autonomous Agents—experienced performance degradation and workflows getting stuck in pending state. The two events, a week apart, shared the same underlying root cause. In each case, new workflow operations were stabilized before all pending workflows were fully recovered. During these windows, affected workflows could experience higher-than-normal latency, fail intermittently, or remain stuck in a pending state until recovery processing completed. This RCA covers two related incidents in the U.S. Region that were subsequently determined to stem from the same root cause: an initial event on June 18, 2026 and a recurrence on June 23, 2026. ## Root Cause The incident was caused by our workflow execution backend exhausting its configured memory capacity and restarting repeatedly. Those restarts disrupted workflow state processing, causing some workflow executions to experience latency, fail intermittently, or remain pending. The primary driver of memory growth was an experimental multi-cluster \(active/passive\) replication feature for disaster recovery purpose. This feature accumulated large, long-lived workflow-history objects in memory faster than they could be released. Each time a history-processing component exceeded its memory limit and restarted, it had to reload its in-flight work—including the replication workload — which drove memory back over the limit and triggered another restart. This self-reinforcing cycle continued until responders intervened, and it was not fully resolved by the initial mitigation applied on June 18, which is why the condition recurred on June 23. ## Detection Both events were detected quickly through automated monitoring, including synthetic tests that continuously exercise the platform and alerts for pending/stuck workflow tasks. At the time of the incidents, there was no dedicated alerting on the memory saturation and restart behavior of the affected components, which lengthened the time required to identify the true root cause. Public status updates began after customer impact was confirmed. ## Response and Recovery A cross-team engineering bridge was established to investigate and mitigate the incidents. Early mitigation attempts focused on scaling backend infrastructure and restarting the affected history-processing components. These provided limited relief because they did not address the underlying memory-growth mechanism. Once the memory-retention path was pinpointed through diagnostic heap analysis, the incidents were mitigated by two actions: **increasing the memory capacity allocated to the affected history-processing components**, and **disabling the multi-clusters replication feature** that was the main contributor to the memory growth. After these changes, new workflow operations returned to normal and the region's capacity to process workflows was restored. Workflows that had become stuck in a pending state were recovered by the engineering team where possible. A small number of workflows that customers had already canceled were not replayed, and a limited set of Agent executions that had failed during the incident had to be retried manually by customers. Both incidents were marked resolved after all recoverable workflows had been processed successfully. ## Follow-Up To prevent recurrence and improve detection, we are implementing the following: 1. Right-size the memory capacity and limits for the affected components, and add automatic memory-cap safeguards so the components stay within safe bounds under load. 2. Redesign and re-validate the cross-region replication feature—including load testing with replication enabled—before it is re-enabled, so it can support disaster-recovery needs without causing memory pressure. 3. Add repeatable memory-diagnostic collection capability and operational runbooks for the service, so memory analysis and mitigation can be performed quickly during future incidents.

Read the full incident report →

Started Jun 18, 2026, 11:17 AM UTC· resolved Jun 18, 2026, 02:22 PM UTC

1. investigating Jun 18, 2026, 11:17 AM UTC

   We are currently investigating reports of an issue in IXP in the Switzerland region. Impact: Customers using IXP in the Switzerland may experience degraded performance and failed requests. Our teams are actively working to identify the cause. Further updates will be shared as soon as more information becomes available.

2. monitoring Jun 18, 2026, 01:46 PM UTC

   A fix has been deployed and the service is recovering. We are monitoring the system to ensure stability and full recovery. Further updates will be shared soon

3. resolved Jun 18, 2026, 02:22 PM UTC

   The issue has been resolved. The system has remained stable during the monitoring period.

4. postmortem Jul 15, 2026, 06:46 AM UTC

   ## Customer Impact Between **June 17, 2026 \(~06:15 UTC\)** and **June 18, 2026 at 14:22 UTC**, customers using IXP in the **Switzerland region** were unable to reliably request document extractions. Affected users saw failed extractions and error messages when annotating documents, and no model training was triggered. The impact was limited to the Switzerland region and affected a single customer, as regional traffic was very low during this period. Customer-facing failures were occurring from the morning of June 17; the issue was formally tracked and resolved as an incident on June 18. ## Root Cause The incident was caused by a deployment configuration issue in the Switzerland region that prevented several GPU-backed IXP service components from starting correctly. This left key document processing services unavailable, resulting in failed document extraction and annotation requests. Existing monitoring did not identify the regional service degradation, delaying detection until the affected customer reported the issue. ## Detection This issue was **not caught by automated monitoring as expected**. Our monitoring reported a number of lower-severity issues during this period but did not surface the more significant region-level outage, so the failure was instead first identified through a **customer report** on June 17 describing failed document annotation in a Swiss tenant. A formal incident was declared on June 18 at 10:46 UTC, and a public status-page update followed at 11:17 UTC. ## Response Following the customer report on June 17, engineering and SRE teams began investigating the issue affecting GPU-backed IXP services in the Switzerland region. Initial attempts to restore service by restarting the affected instances were unsuccessful, and the team continued working directly with the impacted customer while investigating the underlying cause. On June 18, a formal incident was declared and a public status update was published. The investigation identified unhealthy service instances caused by an incorrect deployment configuration. The affected services were restarted with the corrected configuration, a configuration patch was applied to the remaining components, and a corrected service release was deployed. Service health was monitored after recovery, and the incident was resolved once the platform remained stable ## Follow-Up **Planned** * **Improve monitoring:** Implement region-level health monitoring and alerting to detect similar failures automatically, reducing reliance on customer reports for detection. * **Strengthen deployment validation:** Add deployment validation and regression tests to detect missing or invalid configuration before changes reach production. * **Enhance release safeguards:** Review and improve deployment processes to ensure required configuration is consistently applied across all regional service instances.

Read the full incident report →

Started Jun 17, 2026, 11:39 PM UTC· resolved Jun 18, 2026, 01:19 AM UTC

1. identified Jun 17, 2026, 11:39 PM UTC

   We have identified the cause of the degraded performance impacting write operations for Document Understanding in US region and are working on mitigation. Impact: Users may experience failures on some of the write operations. Additional updates will be provided as we move toward resolution.

2. identified Jun 18, 2026, 12:09 AM UTC

   Impact: Users may be unable to write and perform certain operations in US region on Document Understanding. Next update: Our teams are working to understand the cause and scope and will share updates as available.

3. identified Jun 18, 2026, 01:11 AM UTC

   Fix is underway and additional updates will be provided as we move toward. Impact: Users may be unable to write and perform certain operations in US region on Document Understanding.

4. resolved Jun 18, 2026, 01:19 AM UTC

   The outage has been resolved and Document Understanding in US region is fully operational.

5. postmortem Jul 30, 2026, 10:42 AM UTC

   ## Customer impact Between **June 17, 2026 at 23:11 UTC and June 18, 2026 at 1:19 UTC** \(about **2 hours and 8 minutes**\), customers using Document Understanding in the US region experienced failures on write operations and related actions. Because much of Document Understanding's runtime functionality depends on the ability to write data, affected users also experienced broader runtime degradation during this window. The impact was limited to the US region. No data was lost, and the service was fully restored at 1:19 UTC on June 18, 2026. ## Root cause The incident was caused by the Document Understanding production database in the US region reaching its maximum configured storage limit. Once the database reached that limit, operations that needed to write new data failed, which caused disruptions for Document Understanding users. ## Detection The issue was detected by automated application monitoring, which alerted the team within approximately 10 minutes of the onset of impact. Our incident response process was initiated immediately, and responders engaged to investigate. ## Response Responders investigated database storage usage and identified that the database had reached its storage capacity limit. To restore write capability, the team increased the database's capacity. A status page update was published at 23:39 UTC identifying the impact to Document Understanding write operations in the US region, with further updates as the scale-up progressed. Successful operations began recovering at 01:18 UTC, and the incident was resolved at 01:19 UTC on June 18, 2026. ## Follow up We are taking the following actions to prevent recurrence and reduce the impact of similar events: * **Automated storage-capacity alerts** for the Document Understanding databases so the team is warned well before a database approaches its limit. * **Investigating the database's storage growth** to right-size capacity and manage data retention. * **Migrating the database to a higher-capacity tier** so it is no longer constrained by the previous storage ceiling and can scale more quickly.

Read the full incident report →

Started Jun 16, 2026, 08:58 AM UTC· resolved Jun 16, 2026, 01:38 PM UTC

1. identified Jun 16, 2026, 08:58 AM UTC

   We have identified the cause of the degraded performance impacting Azure OpenAI LLM models for Document Understanding in India and are working on mitigation. Mitigation already applied for Europe. Impact: Users may experience intermittent LLM model failures. Additional updates will be provided as we move toward resolution.

2. identified Jun 16, 2026, 10:16 AM UTC

   We have identified the cause of the degraded performance impacting Azure OpenAI LLM models for Document Understanding in India and are working on mitigation. Mitigation already applied for Europe. Contacted and waiting for the LLM model provider (Azure OpenAI) mitigation to take place. Impact: Users may experience intermittent LLM model failures. Additional updates will be provided as we move toward resolution.

3. resolved Jun 16, 2026, 01:38 PM UTC

   The issue has been resolved and availability has returned to expected levels. Impact: No ongoing user impact.

Read the full incident report →

Started Jun 12, 2026, 04:30 AM UTC· resolved Jun 12, 2026, 04:30 AM UTC

1. resolved Jun 12, 2026, 06:27 AM UTC

   UiPath Integration Service in the Australia region, where customers may have experience failures while creating new connections. The issue started at approximately 03:51 AM UTC, 12 June 2026 till 05:59AM UTC, 12 June 2026. Existing connections and running integrations are not impacted. The issue is resolved and service is healthy.

2. postmortem Jul 13, 2026, 03:38 PM UTC

   ## Customer Impact Between **June 11, 2026 at 2:23 pm UTC** and **June 12, 2026 at 6:15 am UTC**, customers in the **Australia region** were unable to create, authenticate, or delete connections through the UiPath Integration Service. During this window, new connection requests failed with an error when attempting to set up, authenticate, or remove a connection. Retrieving existing connections, running workflows, and all previously established connections continued to function normally throughout the incident. Only operations that required establishing, authenticating, or deleting a connection were affected, including requests originating from UiPath Studio Web. Service was restored at approximately **6:15 am UTC on June 12, 2026** once the prior version of the service was redeployed. ## Root Cause A routine deployment to the Integration Service in the Australia region on June 11, 2026 triggered two pre-existing issues that had not previously been encountered together. As a result, the deployment did not complete as expected, causing connection creation, authentication, and deletion requests to fail. Read operations and existing connections were not affected. ## Detection Our monitoring systems detected an elevated error rate on the Integration Service in the Australia region shortly after the disruption began. Around the same time, we received customer reports that connection creation was failing, which corroborated the alert. Our on-call engineering team began investigating. ## Response Our team correlated the onset of failures with the deployment that had completed earlier and confirmed that the deployment had not completed as expected. We decided to roll the service back to the previously stable version. The rollback was performed on **June 12, 2026 at approximately 5:48 am UTC** and completed cleanly within minutes. New connection creation, authentication, and deletion operations returned to normal at approximately **6:15 am UTC**. Following the rollback, our team resolved the underlying issue that had prevented the deployment from completing, to ensure future deployments would not be affected. ## Follow-Up We are making the following changes to prevent this class of incident from recurring: * We have updated our release process to ensure no new version goes live until all required background steps have been fully completed. * Our deployment tooling now automatically detects and resolves internal blockers that could prevent future deployments from completing successfully. * We are auditing configurations across all regions to identify and address similar risks. * We have improved alert routing across all regions, including overnight hours, to ensure faster detection. * We have added deeper monitoring to reduce detection and response time for future incidents.

Read the full incident report →

Started Jun 11, 2026, 10:43 PM UTC· resolved Jun 11, 2026, 11:49 PM UTC

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

Read the full incident report →

Started Jun 10, 2026, 03:51 PM UTC· resolved Jun 10, 2026, 05:05 PM UTC

1. investigating Jun 10, 2026, 03:51 PM UTC

   We are investigating reports of degraded performance impacting Orchestrator workflows and Document Understanding validation experiences in Europe. Impact: Users may experience degraded performance for validation tasks started through Document Understanding APIs. Exceptions for review may also be delayed or may not appear in the Build page.

2. investigating Jun 10, 2026, 03:59 PM UTC

   We are continuing to investigate degraded performance impacting Orchestrator workflows and Document Understanding validation experiences in Europe. Our teams are also assessing the broader service impact, as additional services may be affected. We will share more details as the investigation and rollback progress.

3. investigating Jun 10, 2026, 04:18 PM UTC

   We are continuing to investigate this issue.

4. investigating Jun 10, 2026, 04:20 PM UTC

   We are continuing to investigate degraded performance impacting Orchestrator workflows, Document Understanding validation experiences, and Agents jobs in Europe. Impact: Users may experience degraded performance for validation tasks started through Document Understanding APIs. Exceptions for review may also be delayed or may not appear in the Build page. Users may also see Agents jobs stuck in a pending state.

5. identified Jun 10, 2026, 04:40 PM UTC

   We have identified degraded performance impacting Orchestrator workflows, Document Understanding validation experiences, and Agents jobs in Europe. Impact: Users may experience degraded performance for validation tasks started through Document Understanding APIs. Exceptions for review may also be delayed or may not appear in the Build page. Users may also see Agents jobs stuck in a pending state. Our teams are working on mitigating the issue and assessing the broader service impact, as additional services may be affected. We will share more details as mitigation progresses.

6. resolved Jun 10, 2026, 05:05 PM UTC

   A fix has been applied, and the issue impacting Orchestrator workflows, Document Understanding validation experiences, and Agents jobs in Europe has been resolved. Impact: Users may have experienced degraded performance for validation tasks started through Document Understanding APIs, delays or missing exceptions for review in the Build page, and Agents jobs stuck in a pending state. We are continuing to monitor service health to ensure stability.

7. postmortem Jun 12, 2026, 08:21 AM UTC

   ## Customer Impact Between June 10, 2026, 14:15 and 16:35 UTC, customers hosted in the Europe region experienced delays or failures in services that rely on internal event processing. Affected functionality included: * Jobs remaining in a pending state or failing to start * UiPath Document Understanding™ operations timing out or failing * Automation Solutions installation and uninstallation operations timing out * Delays in synchronization of resources such as folders, processes, queues, and tags No data was lost during the incident. Events that could not be processed during the disruption were automatically processed after service was restored. Total duration: approximately 2 hours and 20 minutes. ## Root Cause ## Root Cause The incident was caused by a configuration issue during a planned infrastructure migration in the North Europe region. A required configuration update was not fully applied across all service components before traffic was moved to the new infrastructure. As a result, some services were unable to communicate with the messaging system they depend on, causing delays and failures in affected operations. Recovery took longer than expected because a separate issue temporarily delayed the rollout of the corrective configuration. Once the configuration was successfully applied, service was restored. ## Detection At 14:52 UTC, our messaging team observed a drop in traffic to the original backend. This was initially attributed to the normal, seasonal decline in traffic that occurs after business hours. On closer inspection it became clear this was a genuine anomaly: traffic to the original backend had dropped as expected when the failover was triggered, but the corresponding increase in traffic to the new backend did not fully materialize. This discrepancy prompted an immediate investigation. Internal service alerts for pending jobs, Document Understanding test failures, and Automation Solutions timeouts also fired during this period, corroborating the customer impact. We confirmed at 15:25 UTC that Orchestrator was receiving "not found" errors when attempting to reach the messaging component. ## Response * **14:07 UTC** — A configuration change to trigger the on-demand failover was merged. * **14:15 UTC** — Orchestrator began receiving "not found" errors when connecting to the messaging component. * **14:52 UTC** — Our messaging team detected a traffic anomaly and began investigating. * **15:03 UTC** — A change to revert the failover was prepared. * **15:10 UTC** — The revert was merged; however, the configuration-propagation automation did not run due to an ongoing GitHub incident. * **15:20 UTC** — GitHub publicly reported its incident, confirming why our configuration changes were not propagating. * **15:25 UTC** — We confirmed the impact to Orchestrator and engaged the team responsible for configuration propagation. * **16:35 UTC** — The corrective configuration propagated to the affected clusters once GitHub recovered; errors stopped and service was restored. Events that were not delivered during the impact window were replayed. ## Follow-Up We are implementing the following improvements: 1. **Improved alerting in Orchestrator** to detect and surface errors from internal messaging endpoints more quickly, reducing the time to detection. 2. **Pre-change verification** to confirm that new backend configuration has fully reached all clusters before a traffic switch is initiated. 3. **Reducing our dependence on a single external provider** in the configuration-propagation path, so that corrective changes can still be applied when an upstream provider is degraded.

Read the full incident report →

Started Jun 10, 2026, 11:00 AM UTC· resolved Jun 10, 2026, 11:00 AM UTC

1. resolved Jun 10, 2026, 03:36 PM UTC

   From 10 June 2026, 11:00 AM UTC to 2:20 PM UTC, Serverless Robots in the US region experienced intermittent latency due to temporary resource constraints. The issue was identified and mitigated by the engineering team, and service performance has since returned to normal.

2. postmortem Jun 18, 2026, 08:09 AM UTC

   ## Customer Impact Between June 10, 2026 at 11:00 am UTC and 2:20 pm UTC, customers using UiPath Serverless Robots in the U.S. region experienced intermittent delays and failures when starting serverless jobs. Affected jobs took longer than expected to start, and some jobs experienced delays of several minutes before execution. In some cases, jobs failed to start successfully during the impact window. ## Root Cause The incident was caused by a configuration issue that, under certain conditions, allowed an unusually high number of jobs to be submitted for concurrent processing. While UiPath Serverless Robots infrastructure automatically scales to meet demand, the surge in concurrent workload increased faster than additional capacity could be provisioned. This created temporary resource contention that degraded scheduling performance and resulted in delays and failures when starting serverless jobs. ## Detection The issue was identified through automated monitoring that detected increased latency affecting UiPath Serverless Robots. ## Response Engineering Team investigated the performance degradation and identified resource contention affecting UiPath Serverless Robots. The workload responsible for the increased resource consumption was isolated, restoring capacity for UiPath Serverless Robots and returning job start times to normal levels. Monitoring continued after recovery to confirm stable service performance. ## Follow Up We have corrected the configuration that contributed to this issue and increased available capacity for UiPath Serverless Robots. We are implementing additional safeguards to prevent similar workload spikes from affecting service performance and have strengthened monitoring to detect this class of issue earlier.

Read the full incident report →

Started Jun 02, 2026, 06:30 PM UTC· resolved Jun 03, 2026, 02:30 PM UTC

1. resolved Jun 03, 2026, 12:34 PM UTC

   On 3rd June 2026, between 00:16 UTC and 02:17 UTC, customers in the Japan region may have experienced intermittent slowness while accessing the UiPath Platform. During a brief window near the end of this period — approximately 02:15 UTC to 02:17 UTC — the impact was more severe: a large majority of requests to the region failed for roughly two minutes before service automatically recovered. The issue has since been mitigated, and all services have returned to normal operation. A detailed Root Cause Analysis will be shared separately.

2. postmortem Jun 12, 2026, 12:37 PM UTC

   ## Customer impact Between June 3, 2026 at 12:30 am UTC and 2:22 am UTC, a subset of customers in the Japan region experienced increased latency and intermittent errors across the **UiPath Commercial Cloud**, most visibly in **Orchestrator**, **Studio Web**, and **Access Policy \(IP Restrictions\)** functionality. The impact lasted approximately 1 hour and 52 minutes. Service performance returned to normal once the underlying infrastructure issue was resolved. ## Root cause The incident was caused by an infrastructure issue within Microsoft Azure API Management in the Japan region. An underlying platform component experienced a failure that gradually degraded request processing and caused intermittent connection issues. This resulted in increased latency and errors for affected services. Service recovered automatically once the underlying platform component returned to normal operation. ## Detection The issue was detected through automated monitoring for elevated API gateway error rates on June 3, 2026 at 2:48 am UTC — approximately 32 minutes after the start of the observed customer-impact window. The alert created the incident response channel, and responders acknowledged the alert immediately. ## Response ‌ After the issue was detected, engineers investigated the increase in latency and errors affecting the Japan region. The investigation confirmed that the disruption originated from an underlying infrastructure issue within Azure API Management. Service performance had already returned to normal by the time the investigation began, and monitoring confirmed stable operation throughout the remainder of the incident review. ## Follow up 1. Microsoft has confirmed this was a rare infrastructure event caused by a failed VM restart on the APIM platform, and that no customer-side action was required to prevent or mitigate it. 2. We are evaluating additional regional synthetic availability checks for Japan to improve detection speed for similar short-lived APIM disruptions. 3. We are improving alert enrichment for regional APIM error spikes to include automatic blast-radius identification and faster customer-impact assessment.

Read the full incident report →

Started Jun 02, 2026, 05:20 PM UTC· resolved Jun 02, 2026, 06:13 PM UTC

1. identified Jun 02, 2026, 05:20 PM UTC

   We have identified the cause of the degraded performance. Impact: Users may experience latency with the new data from orchestrator in insights in US region Additional updates will be provided as we move toward resolution.

2. identified Jun 02, 2026, 05:23 PM UTC

   We have identified the cause of the degraded performance. We are working on the resolution

3. resolved Jun 02, 2026, 06:13 PM UTC

   Issue is resolved now.

4. postmortem Jul 15, 2026, 07:10 AM UTC

   ## Customer Impact Between **June 1, 2026** and **June 2, 2026 at approximately 19:23 UTC \(3:23 PM ET\)**, customers using **UiPath Insights in the U.S. region** experienced delays in the availability of new data in Insights dashboards and reports. The impact was limited to the U.S. region; all other regions continued to operate normally. During the incident, newly generated robot, job, queue, and licensing data was not reflected in Insights. Previously available dashboards, reports, and historical data remained fully accessible throughout the event. No customer data was lost, modified, or exposed. The issue delayed the processing of new data, and all delayed data was successfully backfilled after service was restored. ## Root Cause The incident was caused by the expiration of a security credential used by UiPath Insights to access cloud storage for data ingestion in the U.S. region. Although the credential had been renewed in advance, the updated credential was not successfully applied, allowing the original credential to expire. As a result, data ingestion pipelines were unable to process new data until the credential was replaced. ## Detection * The interruption was detected by automated monitoring on June 1, 2026. * Initial signals were consistent with a transient condition that typically self-recovers, which delayed identification of the underlying cause. * On June 2, after confirming the interruption was persistent, the team identified the expired credential as the cause and began remediation immediately. ## Response Following confirmation of the persistent issue, a dedicated incident response was initiated on **June 2, 2026**, and the UiPath Status Page was updated to keep customers informed. Engineering generated and applied a new credential with a valid long-term expiration, restarted the affected data ingestion pipelines, and validated that delayed data was successfully backfilled. Service was confirmed fully restored by **19:23 UTC \(3:23 pm ET\)**. ## Follow-Up ### **Completed** * Replaced the expired credential with a new long-term credential. * Restarted and validated all affected data ingestion pipelines. * Confirmed successful backfill of all delayed customer data. ### **Planned** * **Improve credential rotation validation:** Add automated verification to confirm that renewed credentials are successfully applied, have the expected expiration, and can access required storage resources before the rotation process is considered complete. * **Strengthen monitoring:** Enhance alerting to detect credential-related failures earlier and more clearly distinguish persistent failures from transient conditions.

Read the full incident report →

Started May 29, 2026, 06:00 PM UTC· resolved May 29, 2026, 07:26 PM UTC

1. investigating May 29, 2026, 06:00 PM UTC

   We are investigating failures and increased latency with GPT models for IXP. Impact: Users may be unable to use GPT models in IXP. Next update: Our teams are working to understand the cause and scope and will share updates as available.

2. monitoring May 29, 2026, 06:27 PM UTC

   We have rolled back a previous change which was responsible for the issue, and are seeing calls to GPT models succeed again. Next update: we expect no further service disruptions, and will update once we have confirmed all regions are recovered

3. resolved May 29, 2026, 07:26 PM UTC

   The incident is resolved

4. postmortem Jun 08, 2026, 02:27 PM UTC

   ## Customer Impact Between May 23, 2026 and May 29, 2026, a subset of customers globally experienced intermittent issues when using Google Gemini models. The affected functionality was part of the IXP-UCD workflow — specifically the document extraction, intelligent preprocessing, and attribution stages — when configured to use Gemini models. Customers may have experienced increased processing times or failures indicating that content could not be retrieved for processing. On May 29, 2026, a smaller number of customers also experienced a related GPT service disruption, which stemmed from the remediation applied for the Gemini issue. Both issues were resolved on May 29, 2026. ## Root Cause The issue was caused by failures in the process used to retrieve document content for Gemini model requests. Under certain conditions, requests to retrieve content were rejected by the model provider, preventing documents from being processed successfully. This resulted in delays and intermittent failures for the IXP-UCD workflow when using affected Gemini models. A change was implemented to use an alternative content delivery method, which eliminated the Gemini failures. While applying this remediation, a configuration issue briefly disrupted GPT model service; this was identified and corrected the same day. ## Detection The issue was identified through a review of service metrics showing elevated processing delays and customer impact. During the investigation, we identified a monitoring gap that prevented expected alerts from notifying engineering teams as service performance degraded. This delayed escalation and response. ## Response After identifying the issue, the team worked with the model provider to investigate the failures and implement a mitigation. A temporary fix was deployed globally, restoring normal service for affected Gemini workloads. Additional validation and deployment activities were completed across all regions to ensure full recovery. The related GPT disruption, which stemmed from the Gemini remediation, was identified and corrected on May 29, 2026, restoring normal GPT service shortly afterward. ## Follow-Up We are implementing the following improvements: **Short-term improvements** * Address the monitoring gap to ensure elevated processing delays trigger alerts as expected.

Read the full incident report →

Started May 29, 2026, 04:18 PM UTC· resolved May 29, 2026, 05:48 PM UTC

1. investigating May 29, 2026, 04:18 PM UTC

   An issue with an upstream provider may be impacting GPT-4.0-powered functionality for Document Understanding, Agents, IXP, and GenAI Activities across multiple regions, and we are investigating. Impact: Users may experience request failures, increased error rates, or degraded performance when using GPT-4.0-powered features and workflows.

2. identified May 29, 2026, 05:03 PM UTC

   An issue with an upstream provider may be impacting GPT-4.0-powered functionality for Document Understanding, Agents, IXP, and GenAI Activities across multiple regions, and we are investigating. Impact: Users may experience request failures, increased error rates, or degraded performance when using GPT-4.0-powered features and workflows. Our teams have identified a potential mitigation and are actively implementing it to reduce customer impact. We will continue to provide updates as progress is made.

3. resolved May 29, 2026, 05:48 PM UTC

   The mitigation has been successfully implemented, and service has been restored. Impact has been resolved for Document Understanding, Agents, IXP, and GenAI Activities across all affected regions. Users should no longer experience request failures, elevated error rates, or degraded performance when using GPT-4.0-powered features and workflows. We will continue to monitor the services to ensure stability.

4. postmortem Jun 24, 2026, 07:34 AM UTC

   ## Customer impact Between May 29, 2026 at 2:40 pm UTC and May 29, 2026 at 5:48 pm UTC, a subset of customers experienced request failures, elevated error rates, and degraded performance when using GPT-4.0-powered features and workflows. The total customer-impacting duration was 3 hours and 8 minutes. Affected services included Document Understanding, Agents, intelligent extraction processing features, and generative AI activities. Impact was observed across multiple regions, primarily in Europe and Australia. ## Root cause The incident was caused by a service degradation at our upstream model provider, Microsoft Azure OpenAI Service. The affected model families — GPT-4.0, GPT-4.0 Mini, GPT-4.1, and text embeddings — returned failures, timeouts, and HTTP 5XX errors for requests routed to those deployments. Per Azure's Post Incident Review, the degradation was triggered by a provider-side change that caused a surge of internal retry traffic, which overwhelmed the shared routing layer Azure OpenAI uses to distribute inference requests. Because some UiPath services route to Azure OpenAI endpoints in the EU when a model is not available locally, the impact extended from the EU to dependent services in Australia. Azure has since mitigated the incident and confirmed remediation to prevent recurrence, including isolating large internal workloads onto dedicated infrastructure and strengthening overload controls. ## Detection The issue was first detected through automated alerting. Internal monitoring alert triggered on May 29, 2026 at 2:48 pm UTC — approximately 8 minutes after impact began \(the incident start was identified from logs as 2:40 pm UTC\) — and the team began investigating immediately. Shortly afterward, multiple other teams reported that they had received related alerts as well. In the window between this initial detection and formal incident coordination, we worked to characterize the issue, identify its likely cause, and determine the available mitigation options. At 3:43 pm UTC, we opened a dedicated incident channel and joined the response bridge to begin officially assessing customer impact and solutions. Follow-up log analysis confirmed elevated failures across the affected services and models. For context, Azure's monitoring first detected the broader incident at 9:39 am UTC during the earlier Australia East wave. UiPath's customer-facing impact and detection were tied to the later Sweden Central wave, which began at 2:40 pm UTC. ## Response * **2:48 pm UTC** — First alert from monitoring; Investigation began immediately. * **3:43 pm UTC** — Incident channel opened; formal impact and mitigation assessment began. * **3:49 pm UTC** — Affected regions identified as Europe and Australia. * **4:00 pm UTC** — Elevated failures confirmed across Document Understanding, Agents, and generative AI activities, with Document Understanding and Agents most affected. * **4:18 pm UTC** — Public status page updated to reflect degraded GPT-4.0 functionality across multiple regions. * **4:21 pm UTC** — Upstream provider \(Azure OpenAI\) identified as the cause. * **4:27 pm UTC** — Australia region recovered. * **5:09 pm UTC** — EU GPT-4.0 and GPT-4.0 Mini traffic redirected to an alternate model provider; verification confirmed recovery for the redirected models. * **5:24 pm UTC** — Remaining affected models recovered at the provider. * **5:48 pm UTC** — Mitigation confirmed complete and the incident resolved; service restored across all affected regions. ## Follow up **Alternate-provider routing readiness.** We have begun configuring the GPT model families currently served on Azure OpenAI to also be available via Native OpenAI for our EU and US regions, where Native OpenAI availability supports it. This establishes a fast, low-friction failover path: in a similar upstream Azure OpenAI incident affecting these regions, we can quickly redirect the affected GPT model traffic in the EU and US to Native OpenAI, reducing customer impact for those models and regions.

Read the full incident report →

Started May 29, 2026, 07:59 AM UTC· resolved May 29, 2026, 05:11 PM UTC

1. investigating May 29, 2026, 07:59 AM UTC

   We are currently experiencing delays and intermittent failures affecting document extraction that use Gemini models. Users may notice delay or unsuccessful processing requests across all regions. Our team is actively investigating the issue and working to restore normal performance.

2. investigating May 29, 2026, 09:28 AM UTC

   Investigation is ongoing. Our team continues to work toward a finding the root cause and we will share further updates as available.

3. identified May 29, 2026, 10:53 AM UTC

   We have identified the issue and are working on implementing a fix.

4. monitoring May 29, 2026, 11:26 AM UTC

   A fix has been implemented and services are operating normally. We are continuing to monitor the service to ensure stability.

5. monitoring May 29, 2026, 12:56 PM UTC

   We continue to monitor the service and have not observed any further issues so far. The system remains stable, and we will keep monitoring for continued assurance.

6. monitoring May 29, 2026, 02:00 PM UTC

   A fix has been implemented successfully in all regions except Japan, where we are still actively working on resolving the issue. Services in other regions are operating normally. Our team continues to investigate and implement the fix for the Japan region, and we will provide further updates as soon as possible.

7. monitoring May 29, 2026, 03:30 PM UTC

   The fix has been deployed in the Japan region and we are validating its effectiveness. Additional testing is underway to confirm recovery. Services in all other regions remain fully operational. We will share further updates as they become available.

8. monitoring May 29, 2026, 04:39 PM UTC

   We have applied and confirmed the fix in several regions, are are continuing to roll it out

9. monitoring May 29, 2026, 04:46 PM UTC

   All regions are fully operational. We will perform validations, and share any further updates as they become available

10. resolved May 29, 2026, 05:11 PM UTC

    The outage has been resolved and IXP is fully operational. Impact: No ongoing user impact.

11. postmortem Jun 08, 2026, 02:28 PM UTC

    ## Customer Impact Between May 23, 2026 and May 29, 2026, a subset of customers globally experienced intermittent issues when using Google Gemini models. The affected functionality was part of the IXP-UCD workflow — specifically the document extraction, intelligent preprocessing, and attribution stages — when configured to use Gemini models. Customers may have experienced increased processing times or failures indicating that content could not be retrieved for processing. On May 29, 2026, a smaller number of customers also experienced a related GPT service disruption, which stemmed from the remediation applied for the Gemini issue. Both issues were resolved on May 29, 2026. ## Root Cause The issue was caused by failures in the process used to retrieve document content for Gemini model requests. Under certain conditions, requests to retrieve content were rejected by the model provider, preventing documents from being processed successfully. This resulted in delays and intermittent failures for the IXP-UCD workflow when using affected Gemini models. A change was implemented to use an alternative content delivery method, which eliminated the Gemini failures. While applying this remediation, a configuration issue briefly disrupted GPT model service; this was identified and corrected the same day. ## Detection The issue was identified through a review of service metrics showing elevated processing delays and customer impact. During the investigation, we identified a monitoring gap that prevented expected alerts from notifying engineering teams as service performance degraded. This delayed escalation and response. ## Response After identifying the issue, the team worked with the model provider to investigate the failures and implement a mitigation. A temporary fix was deployed globally, restoring normal service for affected Gemini workloads. Additional validation and deployment activities were completed across all regions to ensure full recovery. The related GPT disruption, which stemmed from the Gemini remediation, was identified and corrected on May 29, 2026, restoring normal GPT service shortly afterward. ## Follow-Up We are implementing the following improvements: **Short-term improvements** * Address the monitoring gap to ensure elevated processing delays trigger alerts as expected.

Read the full incident report →

Started May 28, 2026, 03:08 PM UTC· resolved May 28, 2026, 03:25 PM UTC

1. investigating May 28, 2026, 03:08 PM UTC

   We are investigating an issue impacting IXP and Communication Mining caused by a database outage. Our team is actively working to restore service and will provide updates as they become available.

2. monitoring May 28, 2026, 03:20 PM UTC

   The database issue impacting IXP and Communication Mining has been resolved, and services are recovering normally. Our team is monitoring the systems closely to ensure continued stability.

3. resolved May 28, 2026, 03:25 PM UTC

   The issue has been fully resolved, and all systems are operating normally.

4. postmortem Jun 05, 2026, 03:37 PM UTC

   ## Customer impact Between May 28, 2026 at 2:48 pm UTC and May 28, 2026 at 3:25 pm UTC, a database outage impacted the IXP and Communications Mining services. Affected customers may have experienced errors, degraded availability, or inability to use features that depend on those services. The impact was limited to a subset of customers in the U.S. region. The total incident duration was 37 minutes. ## Root cause The root cause was an outage of the database used by IXP. IXP services depend on the affected database and so they were unable to operate normally whilst it was unavailable. The relevant database servers had run out of storage space due to organic growth requiring a manual scale-up of the storage volumes. ## Detection The issue was detected through an automated alert at 2:48 pm UTC on May 28, 2026. The alert was triggered and acknowledged within seconds. A public status update was posted at 3:08 pm UTC confirming that our engineering team was investigating a database outage impacting the affected services. ## Response At 2:48 pm UTC, the alert was acknowledged and our engineering team began coordinating the response. At 3:08 pm UTC, the public status page was updated to indicate that we were investigating an issue impacting IXP and Communications Mining services caused by a database outage. By 3:20 pm UTC, the database issue had been resolved by scaling up storage, and services were recovering normally. The incident was marked mitigated at 3:20 pm UTC while our team monitored the affected systems for stability. At 3:25 pm UTC, the incident was marked resolved and the public status page was updated to confirm that all systems were operating normally. ## Follow up 1. Alerts that would have given early warning of database storage filling up had not yet been implemented in the relevant environment. They are now being progressed urgently.

Read the full incident report →

Started May 26, 2026, 01:30 PM UTC· resolved May 26, 2026, 01:51 PM UTC

1. identified May 26, 2026, 01:30 PM UTC

   We identified an issue where robot allocations made at the tenant level were not being reflected in Orchestrator. The root cause was traced to messages throttling caused by exceeded storage quotas. Stale duplicate subscriptions with no active consumers had accumulated unread messages, exhausting the storage limit and blocking new message delivery.

2. monitoring May 26, 2026, 01:46 PM UTC

   The stale subscriptions have been cleaned up and message delivery has been restored. Robot allocation changes are now propagating to Orchestrator as expected. We are actively monitoring the system to ensure stability and confirm no further throttling occurs.

3. resolved May 26, 2026, 01:51 PM UTC

   The issue has been fully resolved and service is back to operational.

4. postmortem Jun 03, 2026, 02:30 PM UTC

   ## Customer impact Between May 26, 2026 at 11:05 AM UTC and May 26, 2026 at 1:46 PM UTC, a subset of customers experienced delays or failures when robot allocation changes made at the tenant level were reflected in Orchestrator. Customers could see a discrepancy between the number of robots shown in the tenant allocation panel and the number available in Orchestrator. The impact was global and affected Orchestrator robot allocation propagation across all regions. The service remained partially operational, but allocation updates did not reliably synchronize. ## Root cause The root cause was storage quota exhaustion in the messaging infrastructure used to notify Orchestrator about licensing and robot allocation changes. Duplicate messaging subscriptions that had no active consumers accumulated unread messages over time. Because message expiration on these subscriptions was configured to retain messages indefinitely, the accumulated messages exhausted the available storage quota. This triggered throttling that blocked delivery of new allocation-change messages to Orchestrator. Because Orchestrator depends on those messages to receive tenant-level allocation updates, some allocation changes were not reflected until the unused subscriptions were removed and message delivery resumed. ## Detection The incident was detected via a customer report at 11:05 AM UTC describing tenant-level robot allocation changes not appearing in Orchestrator. We do have synthetic checks in place for this flow, but because allocation propagation was succeeding intermittently rather than failing outright, the checks did not consistently fail and therefore did not raise an alert. As a result, detection relied entirely on the inbound customer signal. From the initial customer report at 11:05 AM UTC to the point at which engineering documented impact and opened incident at 1:15 PM UTC, roughly **2 hours and 10 minutes** elapsed while the symptom was being reproduced, scoped, and routed to the correct service owners. ## Response At 1:15 PM UTC, our engineering team documented the impact as tenant-level robot allocations not consistently appearing in Orchestrator. By 1:17 PM UTC, analysis identified that notification messages to Orchestrator were blocked by throttling caused by exceeded messaging storage quotas. At 1:30 PM UTC, our public status page was updated to reflect that the issue had been identified. Mitigation initially focused on draining the unused subscriptions by reducing message retention settings and attempting to purge accumulated messages. Neither approach cleared the backlog in production. The effective mitigation was to delete the unused duplicate subscriptions that had high unread message counts, while keeping the active subscriptions in place. After the unused subscriptions were removed, a test allocation change was confirmed to appear correctly in Orchestrator during the response call, and the messaging storage usage dropped from full capacity to a healthy level. At 1:46 PM UTC, our public status was moved to monitoring, with message delivery restored and robot allocation changes propagating as expected. The incident was marked resolved at 1:51 PM UTC. ## Follow up 1. Strengthen alerting on messaging storage quotas and per-subscription backlogs, and tune our synthetic checks to detect intermittent allocation-propagation failures rather than only full outages. 2. Clean up remaining duplicate messaging subscriptions that are not actively consumed, so they cannot accumulate unread messages and exhaust storage again. 3. Review why reducing message retention and purging messages did not clear the backlog in production, and use those findings to define a safer recovery procedure for similar events. 4. Run a bulk synchronization from our licensing system to propagate all current allocations to Orchestrator, so impacted customers do not need to re-allocate manually.

Read the full incident report →

Started May 21, 2026, 09:00 AM UTC· resolved May 21, 2026, 09:00 AM UTC

1. resolved May 25, 2026, 09:46 AM UTC

   Between 21 May 2026 09:00 UTC and 25 May 2026 09:00 UTC, customers on the Community(Europe) region experienced intermittent disruptions to certain features like Solution install and uninstall and Studio Web Debug. Full impact scope is still being validated. The issue was traced to an internal configuration change in a UiPath service and has since been corrected. Service is operating normally.

2. postmortem May 27, 2026, 12:27 PM UTC

   ## Customer Impact Between May 21, 2026, 09:00 UTC and May 25, 2026, 09:00 UTC, a very small subset of customers in the Europe region saw intermittent failures across several Automation Cloud features: * Solution install and uninstall timeouts * Studio Web debug sessions failing to start or complete * UiPath Agents and Maestro jobs stuck waiting on Action Center task completion * Folder synchronization issues across Solutions, Notifications, LLM gateway, and related cloud platform services * User licenses not deallocating after assignment changes All other regions were unaffected. ## Root Cause On May 21 at 09:00 UTC, a planned infrastructure migration transitioned an internal messaging service to a new deployment environment. During the migration, a required runtime configuration governing downstream subscription handlers was not carried over correctly. As a result, certain handlers were treated as inactive, causing related events to be dropped. These subscription handlers support several internal services. Depending on the affected service functionality, some operations experienced delays, timeouts, or completed in an inconsistent state. ## Detection The first signals came from support tickets about Solution install/uninstall timeouts and from internal users hitting Studio Web debug failures. Automated alerts for elevated Solutions errors did fire, but at a non-critical severity, and the symptoms looked feature-specific rather than like a messaging-events layer issue. Because the failures were distributed across several seemingly unrelated features, correlating them back to the messaging migration took longer than it should have. The customer-facing status page entry was published retrospectively, after the cause was understood and corrected. ## Resolution On May 25 at 09:00 UTC, we applied the missing configuration to the new deployment and event delivery to subscribed internal services resumed. After that, we replayed whatever events could be safely re-emitted, so downstream services could reconcile. ## Follow-up Actions * Enforcement of pre-deployment configuration validations. * Tune Solutions service-side alerting: thresholds for failed installs and uninstalls should fire a High severity alert earlier instead of emitting a low-severity signal. * Messaging service events anomaly detection: Alerts for service on sudden drops in delivery rates and rising failure rates.

Read the full incident report →