UiPath Outage History

Started May 20, 2026, 03:58 PM UTC· resolved May 20, 2026, 04:13 PM UTC

1. monitoring May 20, 2026, 03:58 PM UTC

   The issue has been mitigated and resolved. Services are now operating normally. We will continue to monitor the environment to ensure stability.

2. resolved May 20, 2026, 04:13 PM UTC

   The outage has been resolved and Service is fully operational.

3. postmortem Jun 10, 2026, 07:07 PM UTC

   ## Customer Impact Between May 20, 2026 at 3:46 pm UTC and May 20, 2026 at 3:59 pm UTC, the Location Service in UiPath Commercial Cloud was unavailable for a subset of customers. Affected customers in the US region may have been unable to use functionality that depends on the Location Service during this 13 minutes incident. The incident was declared customer-impacting at 3:47 pm UTC on May 20, 2026, and our public status page was updated to reflect the disruption. ## Root Cause The incident was triggered by a rollout of a new version of Location Service. The application version was healthy, but the rollout configuration incorrectly under-provisioned the canary deployment. A bug in the canary configuration made the canary start with only a replica count of 1 instead of having parity with the number of replicas in the primary deployment. As the canary runs in steps and as each step created a new replica set, the issue started to manifest once the canary started to serve a higher and higher percentage of the traffic but with not enough capacity for handling all allocated traffic. Location Service became partially unavailable; the incident was treated as customer-impacting; mitigation was reported at 3:58 pm UTC, once the switch to the new primary replica set, started with a correct number of pods, and the service was confirmed fully operational at 4:13 pm UTC on May 20, 2026. ## Detection Monitoring alerted immediately, and the incident was classified customer-impacting within one minute. ## Response At 3:46 pm UTC, the automated alert fired and our engineering team began coordinating a response. By 3:47 pm UTC, the incident was classified as customer-impacting and a public status page entry was created to keep customers informed. At 3:58 pm UTC, the public status page was updated to "Monitoring," confirming that the issue had been mitigated and that services were operating normally. At 3:59 pm UTC, the service was confirmed as available. At 4:13 pm UTC, the public status page was updated to "Resolved," confirming that the outage had been fully resolved and the Location Service was operational. The incident was formally closed at 4:14 pm UTC. ## Follow-Up 1. The bug in the canary mechanism has been fixed and released: the number of minReplicas for the canary is now aligned with the primary deployment. 2. The canary mechanism has also been changed so a new replica set is not created for each step, reducing any chance of disruption due to pods restart problems

Read the full incident report →

Started May 18, 2026, 11:12 AM UTC· resolved May 18, 2026, 06:43 PM UTC

1. investigating May 18, 2026, 11:12 AM UTC

   We are seeing issue with Microsoft team connecters. We will continue to provide updates as our investigation progresses.

2. identified May 18, 2026, 12:30 PM UTC

   The issue has been identified and a fix is being implemented.

3. identified May 18, 2026, 01:32 PM UTC

   We are continuing to work on a fix for this issue.

4. identified May 18, 2026, 02:46 PM UTC

   We are currently applying a fix across all regions. Thank you for your patience.

5. identified May 18, 2026, 04:21 PM UTC

   The rollout is ongoing but taking longer than expected. We will provide another update once the deployment is fully complete. Thank you for your patience.

6. monitoring May 18, 2026, 06:26 PM UTC

   The fix has been deployed. We are monitoring the situation and will close this incident once full stability is confirmed.

7. resolved May 18, 2026, 06:43 PM UTC

   We have confirmed that the issue is fully resolved and all services are functioning normally.

8. postmortem Jul 14, 2026, 12:23 PM UTC

   ## Customer impact Between May 6, 2026 and 6:43 pm UTC on May 18, 2026, actionable messages sent through the Microsoft Teams connector were not working for a subset of customers. Customers using Action Center actionable notifications in Microsoft Teams could receive the message, but clicking the action button would not complete the task or create the expected event. The issue affected the Microsoft Teams connector and Action Center actionable notifications globally. ## Root cause Approximately two weeks before this incident, an update was done to the Microsoft Teams integration migrated from an older Microsoft software development kit to a newer one with a different authentication model. The newer model required tenant-specific authentication for the Microsoft Teams bot, but one endpoint used by actionable notifications was still configured with the previous shared authentication approach. Because a separate endpoint was updated correctly and appeared to work, the misconfiguration in the actionable-notifications endpoint went undetected. Requests from Microsoft Teams actionable messages could not be authenticated at that endpoint, which prevented action submissions from completing. Customers could not complete Action Center tasks directly from Microsoft Teams. ## Detection The issue was identified during functional testing of actionable notifications across supported communication channels. Additional testing confirmed that the issue affected Microsoft Teams across multiple production regions, indicating that it was not isolated to a single environment. At the time of the incident, automated end-to-end tests did not exist for this workflow. The incident was declared at 10:54 am UTC on May 18, 2026. ## Response On May 18, 2026, at 11:12 am UTC, we published an initial customer-facing status update stating that we were investigating an issue affecting Microsoft Teams connectors. After identifying the authentication mismatch, we developed a fix, validated it in a pre-production environment, and began deploying it to production. During validation, we determined that the initial fix only partially restored functionality. We reverted the recent SDK-related changes affecting this workflow and redeployed the previous implementation. We continued to provide status updates while deployment progressed across production environments. Deployment was completed by 6:26 pm UTC on May 18, 2026. After confirming that actionable notifications were functioning correctly across all production environments and monitoring the service for stability, we resolved the incident at 6:43 pm UTC on May 18, 2026. ## Follow up 1. Add end-to-end automated testing for the Microsoft Teams actionable notification flow, including sending a notification and submitting an action from Microsoft Teams. 2. Add post-deployment validation for changes that affect the Microsoft Teams connector code path, so authentication and action-submission regressions are caught before broad production rollout.

Read the full incident report →

Started May 14, 2026, 09:39 PM UTC· resolved May 15, 2026, 12:52 AM UTC

1. investigating May 14, 2026, 09:39 PM UTC

   We are investigating reports of an outage impacting document processing for Document Understanding in US. Impact: Users may be unable to process documents. Next update: Our teams are working to understand the cause and scope and will share updates as available.

2. investigating May 14, 2026, 10:57 PM UTC

   We are still investigating reports of an outage impacting document processing for Document Understanding in US. Impact: Users may be unable to process documents. Next update: Our teams are working to understand the cause and scope and will share updates as available.

3. monitoring May 14, 2026, 11:49 PM UTC

   A fix has been deployed for the issue impacting document processing for Document Understanding in US, and we are monitoring closely. Impact: Users may still experience issues with document processing. Next update: We are continuing to monitor system behavior.

4. resolved May 15, 2026, 12:52 AM UTC

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

5. postmortem Jun 03, 2026, 06:02 AM UTC

   ## **Customer Impact** Between **May 14, 2026 at 4:17 pm UTC and May 15, 2026 at 12:52 am UTC**, customers using **Document Understanding** in the **U.S. region** experienced intermittent failures and delays when processing documents. The impact was limited to one Document Understanding extraction flow in the U.S. region. Document Understanding services in other geographies were not affected. ## **Root Cause** The incident was caused by an autoscaling issue in an internal component responsible for making extraction models available to processing nodes. During a traffic increase, this component did not scale out. As a result, some processing nodes spent too much time loading or retrying model loads instead of processing extraction requests. This reduced availability for customer traffic and caused intermittent extraction failures and delays. ## **Detection** The issue was detected by automated monitoring on **May 14, 2026 at approximately 4:17 pm UTC**. The incident response process started shortly afterward, and the public status page was updated after the customer impact was confirmed. ## **Response** Engineering teams confirmed that the impact was isolated to Document Understanding extraction traffic in the U.S. region. The team mitigated the issue by increasing available processing capacity where possible, prioritizing customer extraction workloads, and manually scaling the internal model-loading component. After this mitigation, model loading performance improved and the extraction errors rate returned to zero. Recovery was verified through service health dashboards and error-rate monitoring. The incident was marked resolved on **May 15, 2026 at 12:52 am UTC** after the service remained stable with no ongoing customer impact. ## **Follow-Up** To reduce the likelihood and impact of similar incidents, UiPath is taking the following actions: * Improve autoscaling algorithm for the model-loading component so it responds more effectively to sudden increases in demand. * Add monitoring and alerts for model load delays, model load timeouts, and processing nodes delayed by model loading. * Review Document Understanding capacity buffers and scaling assumptions across regions.

Read the full incident report →

Started May 14, 2026, 06:38 PM UTC· resolved May 14, 2026, 07:43 PM UTC

1. investigating May 14, 2026, 06:38 PM UTC

   We are investigating reports of an outage impacting document processing for [Document Understanding] Impact: Users may be unable to processing documents. Next update: Our teams are working to understand the cause and scope and will share updates as available

2. identified May 14, 2026, 07:00 PM UTC

   We have identified the cause of the outage impacting document processing for Document Understanding in US and are working on a fix. Impact: Users may continue to be unable to process documents. Next update: Our focus is on restoring service as quickly as possible.

3. monitoring May 14, 2026, 07:10 PM UTC

   Document processing for Document Understanding in US is recovered and operational, and we are monitoring closely. Next update: We are continuing to monitor system behavior.

4. resolved May 14, 2026, 07:43 PM UTC

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

5. postmortem Jun 03, 2026, 06:00 AM UTC

   ## **Customer Impact** Between **May 14, 2026 at 4:17 pm UTC and May 15, 2026 at 12:52 am UTC**, customers using **Document Understanding** in the **U.S. region** experienced intermittent failures and delays when processing documents. The impact was limited to one Document Understanding extraction flow in the U.S. region. Document Understanding services in other geographies were not affected. ## **Root Cause** The incident was caused by an autoscaling issue in an internal component responsible for making extraction models available to processing nodes. During a traffic increase, this component did not scale out. As a result, some processing nodes spent too much time loading or retrying model loads instead of processing extraction requests. This reduced availability for customer traffic and caused intermittent extraction failures and delays. ## **Detection** The issue was detected by automated monitoring on **May 14, 2026 at approximately 4:17 pm UTC**. The incident response process started shortly afterward, and the public status page was updated after the customer impact was confirmed. ## **Response** Engineering teams confirmed that the impact was isolated to Document Understanding extraction traffic in the U.S. region. The team mitigated the issue by increasing available processing capacity where possible, prioritizing customer extraction workloads, and manually scaling the internal model-loading component. After this mitigation, model loading performance improved and the extraction errors rate returned to zero. Recovery was verified through service health dashboards and error-rate monitoring. The incident was marked resolved on **May 15, 2026 at 12:52 am UTC** after the service remained stable with no ongoing customer impact. ## **Follow-Up** To reduce the likelihood and impact of similar incidents, UiPath is taking the following actions: * Improve autoscaling algorithm for the model-loading component so it responds more effectively to sudden increases in demand. * Add monitoring and alerts for model load delays, model load timeouts, and processing nodes delayed by model loading. * Review Document Understanding capacity buffers and scaling assumptions across regions.

Read the full incident report →

Started May 13, 2026, 03:06 PM UTC· resolved May 13, 2026, 04:31 PM UTC

1. investigating May 13, 2026, 03:06 PM UTC

   We are investigating reports of an outage impacting for computer vision in US region. Next update: Our teams are working to understand the cause and scope and will share updates as available.

2. identified May 13, 2026, 04:04 PM UTC

   The issue has been identified, and our teams are actively working toward applying a fix

3. monitoring May 13, 2026, 04:16 PM UTC

   The issue has been mitigated and resolved. Services are now operating normally. We will continue to monitor the environment to ensure stability.

4. resolved May 13, 2026, 04:31 PM UTC

   The issue has been mitigated and resolved. Services are now operating normally. We will continue to monitor the environment to ensure stability.

5. postmortem Jun 03, 2026, 06:27 AM UTC

   ## Customer impact Between approximately May 13, 2026 at 14:50 pm UTC and May 13, 2026 at 16:16 pm UTC, a subset of customers using Computer Vision in the U.S. region experienced elevated request failures. The affected requests returned server errors and timeouts, which could cause automations that depend on Computer Vision to fail or require a retry. ## Root cause The incident was caused by a failure in an internal routing component \(the Location Service\) used to direct traffic across UiPath Cloud services. Following a routine restart, new instances of this service were unable to complete startup successfully — the internal configuration used for routing traffic failed to load up in the allocated time and new instances failed to start. Most UiPath services were largely shielded from this failure because they route traffic through a layer that caches Location Service data, allowing them to continue functioning normally even when the Location Service is degraded. Computer Vision, however, uses a different routing path that does not benefit from this cache and must reach the Location Service directly for each request. As a result, Computer Vision in the U.S. region was disproportionately impacted, returning errors and timeouts to customers, while other services largely continued to operate. ## Detection The issue was detected through an automated high-severity incident alert for the Computer Vision service on May 13, 2026 at 14:58 pm UTC, approximately eight minutes after the estimated start of customer impact. ## Response An incident bridge was opened for investigation. The status page was updated at 15:06 UTC to reflect that Computer Vision in the U.S. region was under investigation. At approximately 16:00 UTC, Computer Vision error rates increased further when the remaining healthy instance was replaced during the restart cycle. The response team increased the service compute resource allocation, allowing new instances to complete startup successfully. Within minutes, they passed health checks and began serving traffic, and by ~16:07 UTC error rates had returned close to baseline. The incident was fully mitigated at 16:16 UTC and marked resolved at 16:31 UTC ## Follow-up 1. Ensure enough capacity is allocated to the service for it to handle spinning up new instances. 2. Improve our service startup check's timeout settings to ensure the service has enough time allocated for loading its configuration and starting properly.

Read the full incident report →

Started May 13, 2026, 02:04 PM UTC· resolved May 13, 2026, 02:25 PM UTC

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

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

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

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

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

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

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

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

Read the full incident report →

Started May 11, 2026, 01:33 PM UTC· resolved May 11, 2026, 01:43 PM UTC

1. investigating May 11, 2026, 01:33 PM UTC

   We are investigating the cause of the outage for Orchestrator in Community Region and are working on a fix.

2. monitoring May 11, 2026, 01:39 PM UTC

   A fix has been deployed for Orchestrator in Community region and we are monitoring closely. Next update: We are continuing to monitor system behavior.

3. resolved May 11, 2026, 01:43 PM UTC

   This incident has been resolved and service stability has been confirmed for Orchestrator. Impact: All impacted features are operating normally.

4. postmortem May 26, 2026, 07:37 AM UTC

   ## Customer Impact Between May 11, 2026 at 13:00 UTC and 13:35 UTC, Automation Cloud subset of customers experienced widespread errors and significant slowdowns across Orchestrator. During this 35-minute window, starting and managing automation jobs failed or timed out, and operations that did not directly involve jobs were also degraded as the impact propagated to the rest of the product. Enterprise tenants were not affected. ## Root Cause The incident was triggered by a routine product deployment to Community Orchestrator that included a schema change to an existing column on a core Orchestrator database table — specifically, a change to the column's size. Based on prior changes of a similar shape, the team expected this to be applied as a fast, metadata-only operation with no service impact. In practice, the database applied the change as a heavier operation that required an exclusive lock on that table for the duration of its execution, preventing Orchestrator from reading from or writing to the affected table while the lock was held. Because most parts of Orchestrator share the same database, the saturation caused by the blocked operation propagated to the rest of the product, not only to functionality that directly used the affected table. The lock — and the resulting customer impact — was released when the operation timed out automatically after approximately 35 minutes. ## Detection Automated monitoring detected the issue within minutes of the deployment being applied. A critical alert was fired when database worker utilization on the Community Orchestrator database exceeded its threshold, and our engineering team was paged and acknowledged within minutes. Elevated error rates and latency across multiple Orchestrator APIs were confirmed shortly after through additional service-level alerts. ## Response On-call engineers correlated the saturation alert with the recently applied database change and identified table-level contention as the source of the impact. The team prepared mitigation options, including manually terminating the blocking operation, but service was restored automatically at 13:35 UTC when the operation timed out and released the lock. After recovery, the team verified that connection-pool utilization, throughput, and error rates across Orchestrator had returned to normal levels, and that no in-flight customer operations had been left in an inconsistent state. ## Follow-Up To prevent recurrence, we are implementing the following improvements: * **Stricter review of schema changes before deployment**, including explicit pre-flight verification of whether a given column or table change will actually be applied as a fast metadata-only operation on the target table at its current size and database version — with mandatory sign-off when it will not. * **Improved runbook for database-contention incidents triggered by deployments**, so that on-call engineers can quickly identify a deployment-introduced blocking operation and safely terminate it rather than waiting for an automatic timeout.

Read the full incident report →

Started May 05, 2026, 04:30 PM UTC· resolved May 05, 2026, 04:30 PM UTC

1. resolved May 05, 2026, 07:20 PM UTC

   Between 16:17 and 16:22 UTC on 5/5/2026, a few subset of customers using Computer Vision in US region observed a spike of 500 status code errors due to MLS not being reachable. This issue is resolved and we are actively working on investigating the root cause.

2. postmortem May 19, 2026, 07:18 PM UTC

   ## Customer Impact Between 16:17 and 16:22 UTC on May 5, 2026, a subset of customers using Computer Vision in the US East region experienced a spike in errors when accessing the platform. During this 5-minute window, requests were returning 500 status code errors due to Location Service, a core component responsible for routing platform requests, being temporarily unreachable. ## Root Cause The incident was triggered by a planned infrastructure maintenance activity, a routine upgrade to an internal networking mesh component used across all UiPath Platform services. This upgrade caused all services to restart simultaneously, placing unexpected demands on shared compute resources. As a result, the Location Service was unable to spin up replacement instances quickly enough to maintain full capacity. The service ran on limited capacity for approximately 5 minutes, after which the service recovered automatically. ## Detection and Response The issue was identified through internal monitoring and later corroborated through customer reports. A formal investigation was initiated to confirm the root cause. ## Follow-up We take this incident seriously and have already begun implementing improvements to prevent a recurrence. Actions include: * Improving how our infrastructure scales up fast enough and ensuring we maintain minimum required capacity during high-demand events

Read the full incident report →

Started May 05, 2026, 08:22 AM UTC· resolved May 05, 2026, 09:38 AM UTC

1. investigating May 05, 2026, 08:22 AM UTC

   We are investigating reports of a regional outage impacting IXP service in US Region Impact: Users are unable to access IXP services in the affected region. Next update: Our teams are investigating the cause.

2. monitoring May 05, 2026, 08:35 AM UTC

   This issue was limited to a single customer report and the service functioning was not impacted. Next update: We are monitoring closely and will close this incident as soon as we make sure there is no wider impact.

3. resolved May 05, 2026, 09:38 AM UTC

   This issue was limited to a single customer report and the service functioning was not impacted.

4. postmortem May 06, 2026, 01:36 PM UTC

   ## Customer Impact A single customer tenant in the U.S. region experienced a complete inability to use the IXP service. All requests from the affected tenant failed, preventing users from performing both read and write operations, including document processing and automation workflows. ## Scope The issue was isolated to a single customer tenant in the U.S. region. No other customers or regions were affected, and all other services remained fully operational throughout the incident. ## Root Cause The incident was caused by the revocation of access to a customer-managed encryption key required by the affected tenant. This key secures the storage and retrieval of the tenant's data within the IXP service. When the key became inaccessible, the service could no longer decrypt or process any of the tenant's data, causing all requests to fail. ## Detection The first errors occurred on Sunday, May 4, 2026, but the incident was not detected until May 5, 2026 at 8:15 am UTC, when the customer reported being unable to access IXP. A contributing factor was identified in our error handling: the service returned generic server error responses \(HTTP 500\) instead of more descriptive client error responses \(HTTP 4xx\) when the encryption key was inaccessible. This made it harder for the customer to self-diagnose the issue. ## Response Upon detection, our engineering team assembled on an incident bridge and began reviewing error logs and service metrics. The team concluded with high confidence that key access was revoked on the customer's side, likely as part of a security review or key consolidation activity. Recovery was achieved after the customer was contacted and provided with the specific error details. The customer restored UiPath’s access to the encryption key, allowing IXP to function correctly again. ## Follow-up 1. Review detection of CMEK revocation. 2. Correct error responses. Ensure that under CMEK revocation, customers are presented with a clear error message that indicates the issue and how to resolve it.

Read the full incident report →

Started May 01, 2026, 11:44 PM UTC· resolved May 02, 2026, 12:24 AM UTC

1. investigating May 01, 2026, 11:44 PM UTC

   We’re currently experiencing issues with Automation Hub, and some users may be unable to access the service. Our team is actively investigating and implementing mitigation steps. We’ll provide updates as soon as we have more information.

2. investigating May 01, 2026, 11:45 PM UTC

   We’re currently experiencing issues with Automation Hub, and some users may be unable to access the service. Our team is actively investigating and implementing mitigation steps. We’ll provide updates as soon as we have more information.

3. identified May 01, 2026, 11:48 PM UTC

   The issue has been identified, and our team is actively implementing a fix. We’re working to restore full service as quickly as possible.

4. monitoring May 01, 2026, 11:51 PM UTC

   he fix has been deployed, and our team is actively monitoring the system to ensure stability.

5. resolved May 02, 2026, 12:24 AM UTC

   he issue has been fully resolved, and service has been restored. All systems are now operational.

6. postmortem May 26, 2026, 07:47 PM UTC

   ## Customer impact Between May 1, 2026 at 9:45 pm UTC and May 2, 2026 at 11:20 am UTC, customers using a specific Automation Hub GxP environment were unable to sign in. All sign in attempts failed with HTTP 500 errors, blocking access to all Automation Hub features requiring authentication. **Scope:** Only one specific Automation Hub GxP environment was affected. All other Automation Hub environments remained fully operational throughout. ## Root cause The incident was caused by the expiration of a credential used by Automation Hub's sign in service to authenticate with the identity provider. The credential had been rotated the previous week and the updated value was correctly stored in the secure configuration vault. However, the application services in the affected environment were not restarted after the rotation. These services load credentials into memory at startup and do not refresh them automatically, so they continued presenting the expired credential. The outage was delayed by in-memory token caching—the cached token remained valid for a period after the credential expired. The outage began when the cache attempted to refresh and the identity provider rejected the expired credential. No documented procedure existed requiring a service restart after credential rotations, which directly contributed to the oversight. ## Detection Automated monitoring detected the issue at 9:45 pm UTC on May 1, 2026, when sign in failure alerts triggered for the affected environment. Investigation confirmed that all sign in attempts were returning HTTP 500 errors isolated to the authentication service. The engineering team began coordinating incident response at 10:08 pm UTC. ## Response At 10:28 pm UTC, the engineering team convened to investigate. They confirmed that the updated credential was already in the vault and valid, but the running services had not been restarted to load it. The team redeployed all Automation Hub services in the affected environment using the current production version, ensuring no unreleased features were introduced. Redeployment began at approximately 11:14 am UTC on May 2, 2026. By 11:20 am UTC, sign in was restored and monitoring confirmed a 0% error rate. The incident was formally resolved at 11:25 am UTC. ## Follow-up To prevent recurrence, we are implementing the following improvements: 1. **Automated post-rotation restarts:** Adding automated validation to ensure application services are restarted whenever credentials are rotated, eliminating the manual step that was missed. 2. **Proactive credential mismatch detection:** Deploying monitoring to detect discrepancies between credentials in the vault and those in use by running services, enabling early identification of credential drift. 3. **Proactive expiration alerting:** Adding alerts for credentials approaching expiration that have not been loaded by running services. 4. **Updated operational procedures and documentation:** Updating maintenance procedures to require service restarts after credential changes and enhancing credential management documentation for validated environments. These changes are designed to strengthen our authentication infrastructure, reduce reliance on manual steps, and ensure credential rotations are handled seamlessly.

Read the full incident report →

Started May 01, 2026, 05:59 PM UTC· resolved May 01, 2026, 06:37 PM UTC

1. investigating May 01, 2026, 05:59 PM UTC

   Signing With Microsoft is momentarily impacted

2. identified May 01, 2026, 06:10 PM UTC

   The issue has been identified, and the team is actively working on mitigation. Further updates will be shared as progress continues.

3. monitoring May 01, 2026, 06:35 PM UTC

   The issue has been mitigated, and services are now operating normally. We will continue to monitor the situation.”

4. resolved May 01, 2026, 06:37 PM UTC

   The issue has been mitigated, and services are now operating normally. We will continue to monitor the situation.”

5. postmortem Jul 15, 2026, 01:43 AM UTC

   ## Customer Impact Between May 1, 2026 at 5:20 pm UTC and approximately 6:12 pm UTC, customers attempting to sign in to Automation Cloud services using Microsoft \(Sign in with Microsoft\) were unable to complete authentication. Other sign-in methods and existing logged-in sessions were unaffected. The impact was global for customers using Microsoft-based authentication. ## Root Cause The cause was the expiration of a Microsoft Entra ID \(formerly Azure Active Directory\) client secret used to federate Microsoft sign-in to Automation Cloud. When the credential expired, our authentication provider could no longer complete federation with Microsoft, and all new Microsoft sign-in attempts failed. The credential had been due for routine rotation. Internal notifications intended to warn UiPath in advance of expiration did not reach the responsible team in time, and the rotation did not occur before expiration. ## Detection and Response Automated monitoring detected the issue at 5:28 pm UTC, and engineers were paged immediately. The team identified the cause within minutes using existing runbooks, generated a new credential, and applied it to our authentication configuration. The change took approximately 10–15 minutes to propagate across regions of our authentication provider. The last observed sign-in failure occurred at 6:12 pm UTC, and the incident was resolved on our public status page at 6:37 pm UTC. ## Follow-up To reduce the likelihood of recurrence, we are reviewing the credential expiry notification process to ensure the team responsible for rotation reliably receives advance warnings, and auditing ownership coverage across our authentication credentials so notifications reach the right people. We are also evaluating additional preventative alerting on credentials approaching expiration, along with improvements to our incident response tooling for faster coordination on high-severity alerts. We sincerely apologize for the disruption.

Read the full incident report →

Started Apr 30, 2026, 07:43 AM UTC· resolved Apr 30, 2026, 08:24 AM UTC

1. investigating Apr 30, 2026, 07:43 AM UTC

   We are currently investigating an issue where users are unable to access Studio Web in the Australia region. Our team is actively working to identify the root cause and resolve it as quickly as possible.

2. investigating Apr 30, 2026, 08:01 AM UTC

   We are continuing to investigate this issue.

3. monitoring Apr 30, 2026, 08:12 AM UTC

   A fix has been implemented for this issue. We are currently monitoring the service to ensure stability.

4. resolved Apr 30, 2026, 08:24 AM UTC

   The issue has been resolved. Users should now be able to access the service normally.

Read the full incident report →

Started Apr 28, 2026, 10:19 PM UTC· resolved Apr 28, 2026, 11:36 PM UTC

1. investigating Apr 28, 2026, 10:19 PM UTC

   IXP data extractions are currently experiencing delays and intermittent failures in our US region. Our team is actively investigating the root cause.

2. monitoring Apr 28, 2026, 11:07 PM UTC

   A mitigation has been implemented for the IXP data extraction issue, and processing speeds are returning to normal. We are continuing to monitor the system to ensure full stability.

3. resolved Apr 28, 2026, 11:36 PM UTC

   This incident has been resolved. IXP data extractions are processing successfully at normal speeds.

Read the full incident report →

Started Apr 28, 2026, 09:30 PM UTC· resolved Apr 29, 2026, 07:59 AM UTC

1. investigating Apr 28, 2026, 09:30 PM UTC

   Some features may be temporarily unavailable during tenant updates. Our team is actively investigating

2. identified Apr 28, 2026, 09:59 PM UTC

   The issue has been identified, and our team is actively working to resolve it

3. identified Apr 28, 2026, 11:03 PM UTC

   The mitigation efforts are taking longer than initially anticipated, but the team is actively working to resolve the issue as quickly as possible.

4. identified Apr 29, 2026, 12:06 AM UTC

   Our mitigation efforts are continuing as we work toward a full resolution

5. identified Apr 29, 2026, 12:59 AM UTC

   A fix has been implemented, and we are actively monitoring the situation to ensure there are no further issues

6. identified Apr 29, 2026, 02:00 AM UTC

   The deployed fix is still in progress, and we are closely monitoring the environment to observe its behavior and ensure it continues to remain stable.

7. identified Apr 29, 2026, 03:44 AM UTC

   Deployment of the fix is progressing well. We are continuing to monitor the environment closely to ensure stable system behavior.

8. identified Apr 29, 2026, 05:39 AM UTC

   Deployment of the fix is continuing to progress as expected. System behavior remains stable, and we are closely monitoring the environment. We expect this process to take a few more hours and will provide further updates as progress continues.

9. resolved Apr 29, 2026, 07:59 AM UTC

   The issue has been resolved. The fix has been fully deployed and the environment is stable.

10. postmortem May 11, 2026, 03:19 PM UTC

    ## Customer impact Between April 28, 2026 at 8:30 pm UTC and April 29, 2026 at 8:04 am UTC, a subset of customers in the US and EU regions experienced disruptions when adding or editing services within their tenants. Affected customers saw a persistent warning message—"Updating tenant. Some features might be unavailable during the process"—and were unable to add, remove, or access services during this time. In some cases, newly enabled features such as AI-powered services did not appear after being added. Tenants remained stuck in an "updating" state for up to approximately twelve hours during the formal incident window, blocking normal use of the platform. At least one customer experienced this issue for approximately a day before our team identified the broader pattern and began remediation. We understand the significant disruption this caused and sincerely apologize for the impact on your operations. ## Root cause A surge of lower-priority background maintenance tasks—related to deferred data cleanup—overwhelmed the processing queue responsible for managing tenant setup and configuration workflows. These tasks consumed the majority of available processing capacity, creating a growing backlog. As a result, new tenant operations entered a "pending" state but were never picked up for execution, leaving tenants stuck in the "updating" state indefinitely. This issue was compounded by database resource contention: the underlying database infrastructure reached approximately 90% of its processing capacity during the incident, further degrading throughput and slowing recovery. The combination of insufficient queue throughput, a lack of prioritization between critical and routine tasks, and constrained database resources created conditions where essential operations—such as enabling or disabling services—were blocked for an extended period. This pattern is consistent with similar past events where asynchronous state management led to tenants becoming stuck due to unprocessed operations. Recovery required two interventions: manually removing non-essential maintenance tasks from the processing queue to free up capacity, and temporarily increasing database resources to improve throughput. Once these steps were completed, tenant operations resumed and affected customers regained access to their services. A full resolution was confirmed on a per-customer basis before the incident was closed. ## Detection Our monitoring systems raised an alert at 8:29 pm UTC on April 28, 2026, and our engineering team immediately began investigating. By 8:52 pm UTC, the team identified a specific error pattern in service logs indicating that concurrent operations were blocking tenant updates. By 9:13 pm UTC, the issue was formally declared a customer-impacting incident after correlating reports from multiple affected customers exhibiting the same symptoms. While the formal incident window began at approximately 8:30 pm UTC, at least one customer had been experiencing this issue for approximately a day before the broader pattern was identified. This gap highlights an area where we are strengthening our proactive monitoring, as described in our follow-up actions below. Throughout the incident, our team maintained continuous monitoring of the issue's scope and severity, with regular status page updates to keep customers informed. ## Response Our engineering team assembled immediately after detection and began reviewing service logs to identify the cause. * **8:52 pm UTC, April 28:** The team identified the blocking error pattern—concurrent operations preventing tenant updates—and focused investigation on the processing queue. * **9:00 pm UTC, April 28:** The team confirmed that the processing queue was overloaded with lower-priority background maintenance tasks, preventing critical tenant operations from being processed. * **12:13 am UTC, April 29:** The team initiated a cleanup of lower-priority maintenance tasks from the processing queue to free up capacity for critical operations. * **2:28 am UTC, April 29:** The first affected customers were confirmed resolved, with their tenant updates and service access fully restored. * **2:40 am UTC, April 29:** The team confirmed that a significant number of tenants remained in a pending state and continued working to expedite resolution. * **2:56 am UTC, April 29:** Additional database capacity was allocated to improve processing throughput, as the underlying database infrastructure had reached approximately 90% of its processing capacity. * **7:19 am UTC, April 29:** The last tracked affected customer was confirmed fully provisioned. * **8:04 am UTC, April 29:** The incident was fully resolved and normal service was restored. Throughout the response, our team posted regular status page updates and performed targeted verification for each affected customer to confirm resolution before closing the incident. ## Follow-up To prevent recurrence and strengthen our platform's resilience, we are implementing the following improvements: 1. **Automated prioritization of critical operations:** We are updating our processing queue to automatically prioritize essential tenant operations—such as enabling or disabling services—ahead of lower-priority background maintenance tasks. 2. **Investigation into maintenance task surge:** We are conducting a dedicated investigation into the root cause of the unexpected surge in background maintenance tasks that triggered this incident, to prevent similar surges in the future. 3. **Enhanced queue and throughput monitoring:** We are adding automated monitoring and alerting for processing queue backlogs and processing throughput, enabling faster detection before customers are affected. 4. **Database resource saturation alerting:** We are implementing automated alerts for database capacity thresholds to detect resource contention earlier and trigger proactive scaling. 5. **Automated tenant recovery:** We are building periodic reconciliation processes to automatically detect and restore tenants and services to a stable state when operations are delayed or stuck, building on proven remediation strategies from similar past events and reducing reliance on manual intervention. 6. **Increased capacity planning:** We are expanding capacity planning for processing resources during peak operation periods to reduce the risk of bottlenecks. 7. **Improved status communication cadence:** We are refining our status page update processes to ensure more consistent and timely communication during prolonged incidents. 8. **Clearer customer-facing messaging:** We are updating the tenant status messages customers see during updates to provide clearer information about progress and expected resolution times. 9. **Pre-established resolution verification:** We are developing standardized verification procedures to confirm resolution for affected customers more efficiently during future incidents. We sincerely apologize for the disruption this incident caused. We are committed to learning from this event and similar past incidents, and will continue to invest in the reliability and resilience of our platform to minimize the likelihood and impact of similar issues in the future.

Read the full incident report →

Started Apr 27, 2026, 10:11 PM UTC· resolved Apr 27, 2026, 11:21 PM UTC

1. investigating Apr 27, 2026, 10:11 PM UTC

   GPT 4.o mini model is not available and is currently being investigated.

2. investigating Apr 27, 2026, 10:19 PM UTC

   GPT 4.o mini model is not available and is currently being investigated.

3. monitoring Apr 27, 2026, 10:53 PM UTC

   The service is now showing signs of recovery and appears healthy. We are continuing to monitor the situation closely

4. resolved Apr 27, 2026, 11:21 PM UTC

   Service has been fully restored to a healthy state, and the issue has been mitigated.

Read the full incident report →

Started Apr 24, 2026, 04:14 PM UTC· resolved Apr 25, 2026, 12:02 AM UTC

1. identified Apr 24, 2026, 04:14 PM UTC

   The upstream Cloud provider has confirmed an outage impacting VMs for Cloud Robots VM in the US and Delayed US regions Impact: Users may be unable to start robots Next update: We are working with the provider to understand mitigation timelines.

2. identified Apr 24, 2026, 05:05 PM UTC

   We are still awaiting further details from the cloud service provider. We are exploring failover options as well

3. identified Apr 24, 2026, 05:58 PM UTC

   The cloud service provider has identified the issue and started applying a mitigation, we are continuing to follow up with them for more updates. We do not have an ETA for when the mitigation will be completed yet.

4. monitoring Apr 24, 2026, 06:10 PM UTC

   The cloud service provider has applied mitigations and is starting to see improvements from their end. We are monitoring our services to ensure they are recovering as well.

5. monitoring Apr 24, 2026, 06:59 PM UTC

   Some VMs have still not recovered, and the cloud service provider is still actively working on completing their mitigation efforts

6. monitoring Apr 24, 2026, 07:47 PM UTC

   The cloud service provider is still actively working on completing their mitigation efforts

7. monitoring Apr 24, 2026, 08:23 PM UTC

   We are seeing the remaining VMs recover, we will monitor to ensure there is no regression

8. monitoring Apr 24, 2026, 09:17 PM UTC

   While we are not seeing any more impact on Cloud Robot VMs, we are continuing to follow the cloud provider's outage until it is fully resolved.

9. monitoring Apr 24, 2026, 10:10 PM UTC

   We are continuing to follow the cloud provider's outage until it is fully resolved.

10. monitoring Apr 24, 2026, 11:12 PM UTC

    We are continuing to follow the cloud provider's outage until it is fully resolved.

11. resolved Apr 25, 2026, 12:02 AM UTC

    The issue has been resolved

12. postmortem Apr 28, 2026, 04:12 PM UTC

    ## Customer Impact Between approximately 3:00 pm UTC on April 24, 2026, and 12:04 am UTC on April 25, 2026, a subset of customers in the US Region experienced failures when starting, restarting, or provisioning cloud robots \(virtual machines\) through Automation Cloud. Impacted customers encountered errors such as "Partially initialized” or “Failed” status on machines. Existing virtual machines that were already running generally continued to operate, but attempts to provision new machines or restart stopped ones frequently failed. Some customers also experienced delays in job scheduling. The disruption lasted approximately nine hours. We sincerely apologize for the impact this incident had on your automation workflows. We understand that reliable cloud robot availability is critical to your operations, and we take this disruption seriously. ## Root cause The incident was caused by a widespread outage affecting the virtual machine service of our underlying cloud infrastructure provider in the US Region. The provider's outage began at 11:39 am UTC on April 24, 2026—several hours before customer-facing impact became apparent—when a recent deployment to their virtual machine platform introduced a fault that disrupted the ability to start, restart, or provision new virtual machines across multiple availability zones. The outage affected multiple infrastructure services beyond virtual machines, including networking, caching, and container orchestration components. At the time of initial investigation, multiple machines were found with a requested status of "running" but an actual status of "partially initialized," all having transitioned to this failed state within a narrow window around 3:00–3:30 pm UTC. Second, the provider's outage caused connectivity failures within portions of our service infrastructure in the US Region, which led to errors surfacing to the customer while interacting with the platform. ## Detection The incident was first detected at approximately 3:00 pm UTC on April 24, 2026, when the first customer report was received indicating that cloud robots could not be started. Automated monitoring surfaced error patterns including "partially initialized" shortly thereafter. By 3:52 pm UTC, the incident was formally declared and a response team was assembled. Because the failures were mostly limited to VM lifecycle operations, and not all running workloads, existing automated health checks did not trigger for all affected scenarios. There was a gap of approximately 15–20 minutes between the first customer report and full scope determination, as the initial impact was sporadic and became clear only after correlating customer reports with infrastructure telemetry. The team identified multiple machines in a failed state across multiple affected organizations. By 4:15 pm UTC, the scope was sufficiently understood, and a status page update was posted to inform customers of the identified issue. A high-priority support case was also opened with the cloud provider at this time. Notably, the provider's outage had begun at 11:39 am UTC, over three hours before customer-facing impact was detected. The delay between the provider's outage start and observable customer impact is being examined as part of our detection improvement efforts. ## Response Upon detection, our engineering team immediately began investigating the scope and root cause of the failures. By querying internal systems, the team identified that the issue was isolated to the US Region and primarily affected VM start and provisioning operations. The team correlated affected accounts and machines to determine the breadth of impact. Simultaneously, the team investigated broader service degradation and discovered that portions of our service infrastructure in the US Region were experiencing connectivity failures caused by the provider's outage. This caused some platform calls to time out, contributing to automation job scheduling delays. The team traced these failures to specific infrastructure hosts that had been impaired by the provider's outage. The following mitigation actions were taken: * **Service component relocation:** At approximately 6:20 pm UTC, affected service components were relocated from impaired infrastructure hosts to healthy ones. This was performed carefully, one component at a time, to minimize risk. After relocation, the platform service “hypervisor” responded again to calls successfully * **Cloud provider engagement:** A high-priority support case was opened with the cloud provider, and the team monitored their public status page for updates. The provider confirmed at approximately 5:40 pm UTC that they had begun reverting their faulty deployment. The team also submitted a detailed list of affected VM identifiers to the provider's support case to assist their investigation. * **VM recovery testing:** The team conducted targeted tests on affected VMs to verify restoration. Some VMs in certain availability zones remained impacted even after initial mitigations, as the provider's recovery progressed zone by zone. By 8:12 pm UTC, previously affected VMs were confirmed operational, even before the provider had updated their own status page. However, at approximately 10:05 pm UTC, the provider reported a regression in one availability zone and initiated a second corrective action expected to take up to three hours, extending the monitoring period. By April 25, 2026 at 12:04 am UTC, VM operations were consistently succeeding across all availability zones, and the incident was marked as resolved. Throughout the event, we maintained regular status page updates and communicated directly with impacted customers, including proactive outreach to verify that affected machines had returned to normal operation. ## Follow-up To reduce the risk and impact of similar incidents in the future, we are implementing several targeted improvements: 1. **Enhanced detection and alerting:** We are expanding our monitoring to include more granular checks on VM lifecycle operations, ensuring that failures in start, restart, or provisioning actions are surfaced immediately—even when running workloads are unaffected. This includes adding VM health monitoring capabilities that were not previously in place; correcting alert configurations that referenced incorrect regions during this incident, and exploring earlier detection of upstream provider outages before they manifest as customer-facing impact. We are also investigating ways to reduce the three-hour gap between the provider's outage onset and our initial detection of customer impact. 2. **Automated impact correlation:** We are developing automated tooling to rapidly identify affected accounts and machines based on error states, enabling faster scoping and customer notification. During this incident, impact assessment required manual queries, we are automating this process to significantly reduce response time. 3. **Regional failover readiness:** We are investing in infrastructure changes to support more flexible failover and workload migration for cloud robots, including the ability to provision new VMs in alternate regions when a primary region is impaired. Currently, cloud robot VMs are region-bound and no backup provisioning path exists in a secondary region. We are addressing this gap to provide greater resilience against single-region provider outages—a recurring pattern we have observed across similar past events. 4. **Customer guidance and communication:** We are updating our customer-facing documentation and in-product messaging to provide clear guidance on steps to take when VM operations fail due to underlying infrastructure outages. We are also improving our status page update cadence and clarity to keep customers better informed during extended incidents. This incident follows a pattern seen in similar past events, where external platform outages in a single region have disrupted automation services. We are applying lessons learned from those events—including the importance of rapid detection, clear customer communication, and resilient failover strategies—to drive systematic improvements. Our commitment is to continually strengthen our platform's reliability and transparency, so customers can trust Automation Cloud for their most critical workloads.

Read the full incident report →

Started Apr 24, 2026, 11:15 AM UTC· resolved Apr 24, 2026, 11:15 AM UTC

1. resolved Apr 24, 2026, 11:15 AM UTC

   Between 10:00 and 10:20 UTC on 24th of April 2026, several AI-dependent services in the US region were impacted — including Communications Mining, Computer Vision, IXP, Document Understanding, ScreenPlay, and Project Delegate. We understand that some customers were affected, and we will publish a Root Cause Analysis with action items to prevent recurrence.

Read the full incident report →

Started Apr 23, 2026, 05:15 PM UTC· resolved Apr 23, 2026, 09:54 PM UTC

1. investigating Apr 23, 2026, 05:15 PM UTC

   We are investigating reports of an outage impacting Tenant Creation for Orchestrator in Canada. Impact: Users may be unable to Create tenants in Canada Next update: Our teams are working to understand the cause and scope and will share updates as available.

2. investigating Apr 23, 2026, 06:16 PM UTC

   We are continuing to investigate the cause of the outage impacting Tenant Creation for Orchestrator in Canada and are working on a fix. Impact: Users may continue to be unable to Create tenants. Next update: Our focus is on restoring service as quickly as possible.

3. investigating Apr 23, 2026, 07:37 PM UTC

   We continue to investigate the cause of the issue impacting Tenant Creation for Orchestrator in Canada and are working on a fix. Impact: Users may continue to be unable to Create tenants. Next update: Our focus is on restoring service as quickly as possible.

4. identified Apr 23, 2026, 09:05 PM UTC

   We have identified the cause of the outage impacting Tenant creation for Orchestrator in Canada and are working on a fix. Impact: Users may continue to be unable to Create tenants in Canada region Next update: Our focus is on restoring service as quickly as possible.

5. resolved Apr 23, 2026, 09:54 PM UTC

   The issue is resolved and Tenant Creation in Canada is operating as expected. Impact: All user facing functionality is available.

Read the full incident report →

Started Apr 23, 2026, 03:24 PM UTC· resolved Apr 23, 2026, 11:36 PM UTC

1. investigating Apr 23, 2026, 03:24 PM UTC

   We are investigating reports of an outage impacting Agents in US and Europe Regions. Impact: Users may be unable to start Agents. Next update: Our teams are working to understand the cause and scope and will share updates as available.

2. investigating Apr 23, 2026, 04:17 PM UTC

   We are continuing to investigate the cause of the issues, we will provide an update as soon as we begin working on a mitigation

3. investigating Apr 23, 2026, 04:44 PM UTC

   Further investigation has revealed that this issue is affecting all regions, so customers may experience Agents failing to start across all UiPath Automation Cloud regions. We are continuing to investigate the root cause of the issue and will be working to mitigate it promptly.

4. identified Apr 23, 2026, 05:21 PM UTC

   We have identified a defect in a recent deployment, which is causing the issue. We are preparing to roll back the change, which will return Agents to full functionality for all customers.

5. identified Apr 23, 2026, 06:18 PM UTC

   We are validating the reversion of the improper configuration in a lower environment, and will begin deploying it to production regions shortly

6. identified Apr 23, 2026, 07:16 PM UTC

   We are still working on a mitigation for this issue

7. identified Apr 23, 2026, 08:14 PM UTC

   We have a mitigation and are validating it prior to deploying it to production

8. identified Apr 23, 2026, 09:06 PM UTC

   We are continuing to develop and validate a mitigation for this issue

9. identified Apr 23, 2026, 09:29 PM UTC

   We are still working on a mitigation. As a temporary workaround: The issue appears to be related to the IP Restriction security setting, as internal testing has shown that disabling it mitigates the issue. We understand that disabling this feature may not be possible for all customers, but we wish to provide it as an option. In order to apply this mitigation: navigate to Admin -> Security Settings -> IP Restriction

10. identified Apr 23, 2026, 09:54 PM UTC

    We have identified a mitigation and validated it in a lower environment. We are rolling out the mitigation to all affected regions.

11. monitoring Apr 23, 2026, 10:49 PM UTC

    The mitigation has been rolled out, and we are validating that it has resolved the issue

12. resolved Apr 23, 2026, 11:36 PM UTC

    The issue has been resolved

Read the full incident report →

Started Apr 22, 2026, 02:18 PM UTC· resolved Apr 22, 2026, 03:22 PM UTC

1. monitoring Apr 22, 2026, 02:18 PM UTC

   We identified an issue that caused some IXP models to be unavailable or incorrectly shown as “not found.” A fix has been deployed, and we are continuing to monitor the situation closely. We will share a detailed root cause analysis for this incident at a later time.

2. resolved Apr 22, 2026, 03:22 PM UTC

   In the GXP US region, between 13:28:33 UTC and 13:52:42 UTC on April 22, 2026, customers experienced HTTP 404 errors when retrieving extractions for IXP UCD models, resulting in a full outage of runtime extractions during that period. The issue also impacted CM predictions, with additional 404 errors observed . This issue has since been resolved.

3. postmortem Apr 30, 2026, 03:11 PM UTC

   ### Customer Impact Between April 22, 2026 1:28 pm UTC and April 22, 2026 1:52 pm UTC, some customers in the US region were unable to perform document extractions using IXP. During this window, all extraction and prediction requests against pinned model versions returned HTTP 404 Not Found errors. We sincerely apologize for the disruption this caused to your operations. ### Root Cause The incident was triggered by a deployment of a new release of IXP in the impacted region. A targeted code change that required a manual preparation step to be completed before deployment was released before the manual step was run. In environments with more frequent release schedules, this step was handled automatically by an existing part of the deployment process. However, the US and EU regions follow a less frequent, consolidated release schedule, so this automation was not present and the required manual step was missed. As a result, several components of the model management system began reading data from an incorrect location. Because the required data did not exist, requests for extractions and predictions against pinned model versions returned 404 Not Found errors. ### **Detection** Automated monitoring detected the issue after the deployment completed, at approximately 1:28 pm UTC on April 22, 2026. These monitoring checks, which continuously validate core user workflows including extraction against pinned model versions, began failing as soon as the service started returning errors. ### **Response** Upon detection, our engineering team identified the root cause and manually ran the required step against the affected environment, restoring the model management system to read from the correct location. After a sustained monitoring period to verify stable recovery—including confirmation that automated monitoring checks resumed passing and that traffic returned to normal response patterns—the incident was confirmed as fully resolved at 3:22 pm UTC. ### Follow-Up The IXP delayed release process will be reviewed, with a specific focus on why this issue was not seen in earlier regular releases.

Read the full incident report →

Started Apr 22, 2026, 01:20 PM UTC· resolved Apr 22, 2026, 01:20 PM UTC

1. resolved Apr 22, 2026, 01:20 PM UTC

   From approximately 09:52 UTC to 10:21 UTC, customers in the Japan region may have been unable to access the App Service. This was due to an issue in our deployment pipeline that temporarily affected cluster availability, which has been mitigated. A detailed Root Cause Analysis will be shared separately.

2. postmortem May 26, 2026, 07:35 AM UTC

   ## Customer Impact The App Service in the Japan region was inaccessible for approximately 29 minutes \(09:52 AM – 10:21 AM GMT\). Users relying on the Japan cluster experienced temporary service disruptions during this period. ## Root Cause The incident was caused by a flaw in the deployment pipeline script. While using a new centralized deployment template, Japan \(configured in Ring 2\) was temporarily targeted to unblock progression to a later deployment ring. Although the deployment was not intended to proceed beyond the approval stage, the script triggered unintended behavior during initiation, causing the Japan cluster to become inaccessible. ## Detection The issue was identified when the Japan cluster became unreachable during the deployment process. The pipeline did not halt safely at the expected approval stage, revealing an environment-specific or intermittent issue that had not been observed in lower environments. ## Response The team mitigated the issue by manually rolling back the pods to the previously stable version, restoring service. As follow-up actions, the deployment script will be fixed to prevent similar issues, and the Japan region will be moved from Ring 2 to the final deployment ring to avoid unintended impact during future rollouts. ## Follow Up Script fix \(completed\): The deployment pipeline script has been corrected. The fix was validated through dry runs in lower environments and reviewed by the platform engineering team. Ring reassignment**:** The Japan cluster will be moved from Ring 2 to the final deployment ring, ensuring future rollouts reach Japan only after validation across all earlier rings.

Read the full incident report →

Started Apr 21, 2026, 05:59 PM UTC· resolved Apr 21, 2026, 11:38 PM UTC

1. identified Apr 21, 2026, 05:59 PM UTC

   We have identified the cause of the outage impacting Dashboard for Insights in UAE and are working on a fix. Impact: Users may be unable to access the Insights dashboard Next update: Our focus is on restoring service as quickly as possible.

2. identified Apr 21, 2026, 08:18 PM UTC

   The cause of the outage impacting Dashboard for Insights in UAE has been identified and are working on a fix. Impact: Users may be unable to access the Insights dashboard Next update: Our focus is on restoring service as quickly as possible.

3. resolved Apr 21, 2026, 11:38 PM UTC

   The outage has been resolved and Insights dashboard in UAE is fully operational. Impact: No ongoing user impact.

4. postmortem Apr 24, 2026, 07:42 PM UTC

   ## _Customer Impact_ On **April 17, 2026**, the UiPath **Insights portal and Provisioning service** experienced an outage affecting customers in the **UAE region** following a scheduled deployment. During this period, users were unable to access any of the data in Insights dashboards. The impact began at approximately **12:00 UTC on April 17** and was fully resolved by **23:38 UTC on April 21, 2026**, resulting in a total service disruption of approximately **4 days and 11 hours**. ## _Root Cause_ The outage was triggered by an issue in our deployment process for the UAE region. During a recent service deployment, a required step in our deployment workflow failed silently, which prevented the new version of the Insights portal from being fully activated in UAE. Over time, the older version that remained in service began referencing files that had since been removed as part of routine maintenance, causing the portal to become inaccessible to customers_._ ## _Detection_ The issue was discovered through **UiPath Insights internal alerts** and **automated availability monitoring** in the UAE region. These signals indicated portal unavailability, prompting the engineering team to investigate the deployment pipeline and identify the root cause_._ ## _Response_ Upon detecting the outage, the engineering team investigated the deployment pipeline and identified that a re-deployment was needed to restore service. However, the team encountered two additional issues that had to be resolved first: an outdated infrastructure component introduced a pipeline failure, and a misconfigured integration setting — left over from the initial UAE region setup — had been silently blocking deployments. On **April 21, 2026 at approximately 20:30 UTC**, both issues were resolved, allowing a successful re-deployment that fully restored the Insights portal in UAE by **23:38 UTC on April 21**. ## _Follow-Up_ To prevent similar incidents in the future, we are taking the following steps: * **Establish a mandatory verification checklist for new region deployments** to ensure all configuration settings are correctly applied before going live. * **Ensure any incomplete deployment steps are treated as active incidents** and fully resolved before proceeding with subsequent releases. * **Strengthen monitoring and alerting coverage for recently launched regions** to ensure issues are detected and escalated promptly, regardless of region maturity.

Read the full incident report →

Started Apr 21, 2026, 05:52 PM UTC· resolved Apr 21, 2026, 05:52 PM UTC

1. resolved Apr 21, 2026, 05:52 PM UTC

   From approximately 14:20 UTC to 17:10 UTC, customers in the United States region may have encountered errors when signing in or navigating within the Cloud Portal. This was due to a temporary resource exhaustion on our traffic routing backend, which has been mitigated. We are in the process of increasing the resilience of the system to such situations, to prevent them from affecting customers. The underlying issue also affected some requests to the following services: Computer Vision Notification Service

2. postmortem May 26, 2026, 09:05 PM UTC

   ## Customer Impact On April 21, 2026, between 14:22 and 17:02 UTC, some customers using UiPath services in the U.S. East region experienced intermittent errors when accessing the platform. During this period, a small percentage of requests for approximately 5 minutes returned error responses. Services were restored to full availability by 17:02 UTC with no data loss or data integrity issues. The following services were impacted as a result: Computer Vision, Notification Service \(a core component responsible for routing platform requests\), and Identity \(used for user auth\). ## Root Cause The incident was triggered by a routine platform maintenance job that performs cleanup work after an infrastructure upgrade. As part of this cleanup, every service running in the affected compute cluster was restarted at nearly the same time. The simultaneous restart caused the compute cluster's combined compute and memory demand to briefly exceed what was available, leaving new service instances unable to start. The Location Service was particularly sensitive to this condition at startup and during this phase, its health checks were very strict. Under temporary resource pressure and incoming service traffic, new instances were unable to complete startup sequence quickly enough and were repeatedly marked as unhealthy. A single healthy instance carried most of the full traffic load for approximately 2.5 hours. When that instance was eventually replaced, there was a ~5 minute window during which no instance was fully ready to serve traffic, after which the service recovered automatically. ## Detection and Response The issue was initially identified by our engineering team through internal monitoring. Upon detection, our on-call team was engaged immediately and began an investigation. The service self-recovered by 17:02 UTC, and a formal incident was declared shortly after. A status update was posted at 17:52 UTC. ## Follow-up We have begun implementing improvements to prevent a recurrence. Key actions include: * Adjusting the service startup conditions to make sure new service instances are available before removing the old ones. * Strengthening safeguards to maintain minimum service availability * Improving alerting to detect and notify teams earlier of service instance replica availability issues.

Read the full incident report →

Started Apr 20, 2026, 06:55 PM UTC· resolved Apr 20, 2026, 08:13 PM UTC

1. investigating Apr 20, 2026, 06:55 PM UTC

   Users may be unable to sign-in to Autopilot for Everyone, and may be unable to send messages even if already logged in.

2. monitoring Apr 20, 2026, 07:13 PM UTC

   We have applied a mitigation and are seeing traffic return to normal. We will continue to monitor the situation as it improves

3. resolved Apr 20, 2026, 08:13 PM UTC

   We have applied a mitigation and are seeing traffic return to normal. We will continue to monitor the situation as it improves

4. postmortem Apr 20, 2026, 10:16 PM UTC

   ## Customer Impact ‌ Between approximately 6:00 pm UTC and 7:14 pm UTC on April 20, 2026, customers using the Autopilot for Everyone service in the United States Delayed region were unable to sign in or send chat messages. All attempts to access the service returned errors, rendering the service effectively unavailable. Customers with cached credentials were also unable to send messages, and no workaround was available during the outage. Scope: The impact was limited to customers accessing Autopilot for Everyone via Portal > AI Trust Layer and those using the Autopilot for Everyone via Assistant in the United States Delayed region. ## Root Cause ‌ A service update deployed to the Autopilot for Everyone service on April 20, 2026 triggered an unexpected modification to the traffic routing configuration in the United States Delayed infrastructure. The routing rules that direct incoming customer requests were altered to an unsupported configuration. This mismatch meant that the routing layer could not match incoming requests to any valid destination, resulting in HTTP 404 errors for all service traffic. Recovery was achieved by manually patching the routing configuration to include both the original correct address and the modified address, allowing incoming customer requests to be properly routed and restoring service availability. The exact mechanism by which the infrastructure-level process introduced the incorrect routing address has been determined and we are working on a long-term fix. ## Detection ‌ The incident was first detected at 6:02 pm UTC on April 20, 2026, when automated monitoring reported failures in the Autopilot for Everyone service. Multiple alerts were triggered simultaneously, including service availability checks and automated browser-based tests targeting the affected region, all indicating that the service was unreachable. Engineers observed HTTP 404 errors on all service endpoints, including health checks, along with routing-level "no route" errors confirming that traffic could not reach the service. ## Response The service update that triggered the issue completed at approximately 6:00 pm UTC. The engineering team attempted to revert the change, but the rollback did not resolve the issue. Approximately 43 minutes elapsed between the deployment and attempted rollback. The persistent errors after the revert prompted the team to escalate, formally declare an incident, and begin a coordinated response. Upon detection, our engineering team began investigating the routing configuration and identified that it referenced an incorrect internal address that did not match the address used by incoming customer traffic. A revert of the service update had already been attempted but did not resolve the issue. To confirm the diagnosis, the team performed targeted tests against both the incorrect and correct addresses. Requests sent to the incorrect address returned successfully, while requests using the expected address failed — confirming that the routing configuration was functional but pointing to an unsupported destination. By 7:06 pm UTC, the team had formulated a plan to manually patch the routing configuration by adding the correct address alongside the existing incorrect entry. This additive approach was chosen as a safe, non-destructive fix that would restore service without risking disruption to any processes that might depend on the existing configuration. At 7:11 pm UTC, the routing configuration was patched. Health checks immediately returned successful responses, and automated service monitoring confirmed that the service was recovering. By 7:14 pm UTC, the incident was marked as mitigated and normal functionality was restored. The team continued monitoring the service for approximately one hour, confirming a full recovery with no further failures. The incident was marked as fully resolved at 8:14 pm UTC. ## Follow-up ‌ To prevent similar incidents in the future, we are implementing the following improvements: * Infrastructure process investigation: We have identified why an infrastructure-level process modified the routing configuration. We will follow up with safeguards to ensure that modifications are backwards-compatible with deployments running older releases. We are committed to making our systems more resilient and transparent. These improvements will help us detect configuration issues earlier, reduce recovery times, and deliver a more reliable experience for all customers.

Read the full incident report →

Started Apr 20, 2026, 12:52 PM UTC· resolved Apr 20, 2026, 12:52 PM UTC

1. resolved Apr 20, 2026, 12:52 PM UTC

   Between 12:02 and 12:14 UTC, an issue affecting one of our core services, Orchestrator, caused disruption across multiple services. The incident was triggered by unexpected restarts in the underlying infrastructure supporting Orchestrator. We understand the impact this has had on our customers and apologize for the disruption. We will publish a detailed RCA, including action items to prevent a recurrence.

2. postmortem Apr 24, 2026, 11:38 AM UTC

   ## Customer Impact Between 12:02 pm UTC and 12:15 pm UTC on April 20, 2026, customers in the U.S. region experienced elevated error rates and failed requests when using the Orchestrator service. During this approximately 13-minute window, automation workflows were interrupted and a portion of requests returned errors. Error rates began declining by 12:14 pm UTC and returned to normal by 12:15 pm UTC. Impact was limited to the Orchestrator service in the U.S. region. All other services and regions remained fully operational. ## Root Cause A routine infrastructure upgrade in the U.S. region restarted all servers supporting the Orchestrator service within a four-minute window—far more rapidly than intended. A safeguard designed to limit how many service instances can be unavailable at once was in place, but was not honored during the upgrade, so nearly all Orchestrator instances went offline simultaneously. Remaining capacity was insufficient to serve normal traffic, resulting in widespread errors until instances came back online. The exact mechanism by which the upgrade bypassed the safeguard is under deeper investigation. ## Detection Automated monitoring detected a sudden increase in errors at 12:05 pm UTC—approximately three minutes after the impact began. Engineers acknowledged the alerts and began investigating immediately. Customer reports arrived within the same window and corroborated the alerts. ## Response Engineers assembled on an incident call and quickly identified that all Orchestrator service instances had restarted nearly simultaneously, correlating with an ongoing infrastructure upgrade. Underlying database and service dependencies were verified as healthy, focusing the investigation on the upgrade process itself. The service recovered on its own as instances came back online. **April 20, 2026** * 12:12 pm UTC— Incident call assembled— ongoing upgrade identified as the cause. * 12:14 pm UTC— Error rates dropped below 2% as instances recovered. * 12:15 pm UTC— Service returned to normal operation. * 12:26 pm UTC— Full-service health confirmed—Remaining Orchestrator upgrades paused. * 12:52 pm UTC— Status page updated and the incident was marked resolved shortly after. ## Follow-Up We are implementing improvements to reduce the likelihood of similar incidents. _Short-term improvements_ * Investigate the exact mechanism by which the upgrade bypassed the restart safeguard, and add automated validation to enforce it during all maintenance activities. * Add pre-upgrade verification to confirm service capacity will be maintained before any changes are applied. * Add monitoring and alerts for unexpected patterns of simultaneous service restarts. _Long-term improvements_ * Update operational procedures and team training to reinforce best practices for safe infrastructure upgrades.

Read the full incident report →