UiPath Outage History

### Customer Impact Beginning on March 9, 2026 at 9:49:28 UTC, some customers using Studio Web were unable to load the Maestro canvas. Affected users encountered an error state instead of the expected experience, which blocked them from opening and working with Maestro-based workflows in Studio Web. The issue affected a limited set of organizations across multiple cloud rings, including customer tenants. Other Studio Web capabilities remained available, but Maestro access was disrupted for impacted organizations. Mitigation was completed on March 10, 2026 at 21:55 UTC, resulting in an impact window of approximately 36 hours. ### Root cause A licensing entitlement change intended to limit Maestro availability for Test Cloud licenses was applied too broadly. As a result, the entitlement required to access Maestro was removed for additional organizations that should have retained access. When Studio Web attempted to load Maestro for those affected organizations, the backend treated the service as unavailable, which caused the Maestro frontend module to fail to load and users to see an error instead of the canvas. The issue was not caused by infrastructure instability or a front end deployment failure. It was caused by an incorrect entitlement state for impacted organizations. ### Detection The issue was first identified through reports from internal users and subsequent investigation of telemetry showing repeated Maestro load failures for a distinct set of organizations. Because the failure was tied to an entitlement state rather than a full-service outage, existing alerting did not immediately classify the problem as a customer-facing incident. After the reports were correlated with telemetry and tenant-level impact, engineering confirmed the issue’s scope and declared an incident on March 10, 2026 at 15:15:09Z UTC. A public status update was then posted to notify affected customers. ### Response Once the scope of the issue was understood, engineering teams reviewed entitlement and audit data to determine why affected organizations were being treated as ineligible for Maestro access. Initial mitigation attempts focused on validation and client-side recovery steps, but these did not address the underlying entitlement issues for impacted tenants. Investigation then confirmed that a recent licensing entitlement refresh had removed the required Maestro entitlement from organizations that should have remained enabled. The team reversed the entitlement change to restore the Maestro entitlement for Test Cloud licenses. After the change was rolled back and access was restored for affected organizations, telemetry and manual verification confirmed recovery. In a smaller number of cases, some users continued seeing the error briefly because the prior service-unavailable response had been cached. Those cases were resolved as caches expired or were cleared. ### Follow-Up To reduce the likelihood of similar incidents, we are implementing the following improvements: 1. Improve change review and coordination for entitlement-related updates that can affect customer access to product capabilities. 2. Strengthen validation and rollout safeguards for entitlement changes so that tenant targeting errors are caught before production impacts. 3. Improve Studio Web error handling so entitlement-related failures are surfaced more clearly and are easier to distinguish from generic frontend loading issues. 4. Expand alerting and monitoring for Maestro load failures so canvas load issues are detected earlier. 5. Reduce cache persistence for service-unavailable responses where appropriate, to shorten residual impact after recovery.

## _Customer Impact_ Between March 10, 2026, 10:15 UTC - 13:36 UTC, Data Fabric customers in Europe experienced increased latency and intermittent failures on DataFabric requests across consumption surfaces \(Automation Cloud UI and Workflow Activities\). During this period, some customers were unable to load Data Fabric UI pages or successfully run workflow activities— affected requests frequently timed out or were canceled by the client \(observed as HttpClient timeouts / `TaskCanceledException`\). No durable impact was introduced. ## _Root Cause_ * A large-scale background maintenance job in the Europe ring temporarily increased demand on the database, slowing responses. * At the same time, a deployment and the resulting transient increase in user requests exposed that a subset of service instances did not have enough capacity to absorb the increased, sustained load. * The combination of slower database responses and insufficient transient capacity increased the time requests remained open and caused more work to accumulate on active service instances, which further degraded performance. This resulted in worsening performance and intermittent failures for some customers. ## _Detection_ The issue was first detected by a customer report— and automated alerts were subsequently triggered. ## _Response_ Upon receiving the report, the team immediately triaged the issue and identified elevated dependency latency and unhealthy runtime instances. Around 10:52 UTC, we received the customer report, engaged, and started investigating the issue. We initiated a rollback of the recent deployment at around 12:29 UTC and increased runtime capacity as an stabilizing measure to curb customer impact. These steps together returned the service to a healthy state by 13:36 UTC. ## _Follow-Up_ * Review and align service instance resource allocations across regions so instances have sufficient headroom for transient load. * Improve operational observability to capture runtime diagnostics and memory/health signals earlier. * Add proactive alerts for sustained high resource usage and service restarts. * Implement operational guardrails for background jobs to prevent database overload/pressure.

## _Customer Impact_ Customers using AI Center with tenants located in **India** experienced **degraded** **service** between **March 10, 2026 11:05 am UTC** and **12:40 pm UTC**. During this time, **some operations** related to skills and training pipelines were unavailable. Customers were unable to **start new skills**, **resume** or **stop** existing skills, or **start** new **training pipelines**. Skills that were **already running** **continued** to process requests **normally**, and training pipelines that were already in **progress** were **not affected**. Users saw error messages in the user interface when attempting these operations. Total duration: **approximately 95 minutes**. ## _Root Cause_ A **configuration change** related to network settings prevented AI Center services responsible for managing skills and training pipelines from **communicating** with the infrastructure that runs them. Because of this, requests to **start** or **manage** skills and training jobs could not be completed successfully. ## _Detection_ The issue was detected through **automated testing** systems that identified failures in skill and training operations **shortly** after the problem began. These tests reported errors in both the user interface and backend operations, which indicated a **service disruption**. ## _Response_ Once the issue was detected, engineers began **investigating** the failures affecting AI Center operations. March 10, 2026 * Automated tests **detect** failures in skill and training operations. * Engineers investigated multiple services and confirmed the issue was **not temporary**. * The investigation identified a **network configuration change** that blocked communication between AI Center components. * The configuration was **corrected** to **restore** communication between services. * AI Center services **recovered automatically** once the configuration update was applied. * Service functionality **returned to normal** shortly after the change was deployed. ## _Follow-Up_ We are **taking steps** to **reduce** the likelihood of similar issues in the future. Short-term improvements: * **Review** configuration changes affecting infrastructure connectivity before rollout. * **Validate** cluster configuration updates using **automated checks**. Long-term improvements * **Improve** configuration management processes to better **detect dependency changes**. * Introduce **automated validation and rollback** mechanisms for infrastructure configuration changes. We remain committed to improving the reliability of AI Center and the UiPath Platform™.

**Customer Impact** Between 16:28 UTC and 18:12 UTC \(about 1 hour 44 minutes\), the web summary tool experienced a service disruption. During this window, users were unable to execute summary-dependent tasks within Agents and RPA workflows, resulting in failed process executions. **Root Cause** The incident was triggered by an upstream API authentication failure. Specifically, the integration credentials for the third-party summary provider became invalidated due to an unexpected account configuration change on the provider's side. This led to the rejection of all outbound requests from our service. **Detection** The issue was first reported by a customer. ‌ **Resolution** To restore service, our engineering team provisioned a new API endpoint configuration and refreshed the associated security credentials. This successfully re-established the handshake with the provider, and restored full functionality. **Timeline** * **16:28 UTC:** Issue identified and investigation started. * **16:56 UTC:** Incident officially declared. * **17:00 UTC:** Root cause identified as an upstream credential failure. * **17:30 UTC:** Deployment of new API configuration started. * **17:53 UTC:** Deployment completed. Validation successful across production regions. * **18:12 UTC:** Incident resolved. Monitoring confirmed stability. **Follow-Up Actions** * Use detailed error-rate alerting to spot 4xx/5xx responses from upstream providers right away. This will reduce the reliance on customer reports. * Conduct a post-mortem with the service provider to ensure account configuration stability and prevent future credential invalidation.

## _Customer Impact_ Region\(s\) affected: Global—All regions Service\(s\) affected: Orchestrator Customers using automation workflows with multiple manually configured Package Requirements execution settings, could experience job failures with the following error: > “_Machine doesn’t exist” \(Error code: 1002\)_ The underlying issue was a pre-existing bug that surfaced under a specific sequence of process edits. It was reported on March 6, 2026 and fully resolved on March 10, 2026. ## _Root Cause_ When updating a process with execution settings configured without modifying the execution settings, some settings with empty default values could be incorrectly overwritten. ## _Detection_ The problem was found on March 6, 2026, when a customer service ticket was opened. A customer reported that their automation workflow was failing with a "Machine doesn't exist" error upon execution. The issue had gone undetected until this point, as the bug manifests under a specific sequence of edits and produces no warnings at the time the corrupted data is saved. ## _Response_ Upon receiving the report, engineering triaged the issue and identified the root cause. A workaround was provided to affected customers while a proper fix was developed. The hotfix was rolled out across all regions between March 9–10, 2026, and a database cleanup was applied to remediate all affected processes, fully restoring job execution. ## _Follow-Up_ The bug has been fixed and a database cleanup has been done to fix all affected processes. To prevent recurrence, we are taking the following preventative measures: * Add checks to reject incorrect machine reference values before they are saved. * Incorporating this scenario into our test suite to detect similar issues in future releases.

## Customer Impact On 2026-03-05 between 00:00 and 00:10 UTC, customers in the **United States** region experienced approximately 10 minutes of sign-in delays, temporary access issues, and intermittent functionality errors across Orchestrator, Automation Cloud, Test Manager, and Studio Web. Customers whose organization data is hosted in other regions were not affected. Service behavior returned to normal automatically at 00:10 UTC. No data was lost and no customer action was required. Total customer-impacting duration: **~10 minutes**, 00:00 – 00:10 UTC. ## Root Cause During a routine software update, a temporary reduction in capacity occurred at a transition point in the update. For a brief window, the available capacity could not keep up with normal request volume, which produced the sign-in delays and intermittent errors customers observed. Capacity restored automatically and service returned to normal behavior within ten minutes. ## Detection The incident was detected through automated monitoring. Alerts covering customer-facing response codes, request latency, and underlying service health fired within three minutes and paged the on-call team immediately. No monitoring gaps contributed to the incident. ## Response On-call engineering and site-reliability engaged within one minute of the alerts firing and convened on an incident bridge. By the time the team was assembled, monitoring showed service recovering on its own, no manual mitigation was needed. The team held the bridge to verify stability, confirmed a clean 30-minute observation window with no recurrence, marked the incident mitigated at 00:37 UTC, updated the public status page to resolved at 01:01 UTC, and closed the incident at 01:29 UTC. A full post-incident investigation opened the next day identified the underlying cause. Timeline: * 00:13 UTC — Automated alerts fired; on-call teams paged. * 00:14 UTC — Engineers acknowledged and joined the incident bridge. * 00:10 – 00:37 UTC — Self-recovery confirmed; stability verified against live traffic. * 00:37 UTC — Incident marked mitigated. * 01:01 UTC — Public status page set to resolved. * 01:29 UTC — Incident closed. ## Follow-Up We have already increased the minimum capacity running in production so there is more headroom during future updates. As a longer-term improvement, we are moving this workload onto our modern deployment platform, which rolls out new versions gradually and supports automatic rollback if any issue is detected. This migration is a top engineering priority and is the change that fully addresses the underlying cause.

## Customer impact Between March 3, 2026, at 3:20 pm UTC and March 3, 2026, at 11:49 pm UTC, some customers were unable to access the IXP Platform. During this period, users who were making cross-region requests to IXP were receiving "Not Found" responses. This encompassed the design-time UI, the API, and consumers via Activities. The disruption lasted approximately eight hours and 27 minutes. ## Root cause The incident was triggered by a configuration change to the service routing layer for IXP, specifically a modification to the service routing configuration deployed on March 3, 2026, at 3:20 pm UTC. This change was intended to prepare for an upcoming feature release but inadvertently disrupted cross-region request handling. As a result, requests originating from one region and targeting IXP in another region were blocked or misrouted, causing service unavailability for affected customers. Attempts to roll back the change initially worsened the issue, as the rollback did not restore the previous stable state and introduced additional routing inconsistencies. Recovery required building and deploying a targeted hotfix to restore correct routing behavior across all impacted regions. ## Detection The incident was first detected on March 3, 2026, at 6:21 pm UTC, when clients advised that they were unable to access the IXP design-time UI. Automated monitoring confirmed an issue with cross-region requests since the deployment. The issue was classified as an incident and escalated within minutes, with the status page updated to reflect the outage. Initial investigation began immediately, with engineering teams coordinating in real time. ## Response On March 3, 2026, at 6:21 pm UTC, engineering teams began investigating the root cause, focusing on recent configuration changes to the service routing layer. An initial attempt to fix the issue by reverting a minimal set of changes was unsuccessful at 7:55 pm UTC, and the engineering team started to work on a more robust fix. By 9:07 pm UTC, the issue was identified as a problematic service routing configuration deployed earlier that afternoon. A hotfix was developed and tested in a smaller environment, then deployed to the Japan region to verify resolution. By 10:00 pm UTC, the hotfix was pushed to the EU and US regions, where the majority of affected customers were located. Full recovery was achieved by March 3, 2026, at 11:49 pm UTC, when monitoring confirmed normal operation and customers reported restored access to IXP. The status page was updated to resolved, and no further customer cases were reported. Recovery was verified through automated checks, customer confirmations, and monitoring data, ensuring that cross-region requests to IXP were functioning as expected. ## Follow up To prevent similar incidents, we are implementing several technical and process improvements: * Automated validation checks will be added to pre-production environments, ensuring that changes to service routing layers are tested for cross-region compatibility before rollout. * Enhanced monitoring will be deployed to detect anomalies in cross-region request handling, providing earlier warning and more granular visibility into service health. * We will improve how quickly and precisely we can revert recently deployed changes so that issues can be resolved as soon as possible once they have been diagnosed. These measures build on lessons learned from similar past events, such as the incident involving email delivery disruptions due to configuration changes. We are committed to systematically addressing this pattern by strengthening our deployment safeguards, improving detection capabilities, and ensuring rapid, reliable recovery for our customers. Technical improvements will be rolled out over the coming weeks, with ongoing review to ensure effectiveness and resilience.

## _Customer Impact_ Between February 26, 2026 at 1:30 pm UTC and February 27, 2026 at 3:40 pm UTC, few customers experienced workflow failures when using Bring Your Own \(BYO\) large language model \(LLM\) configurations. Workflows that connected to external AI providers, such as Vertex AI and other supported LLM services, returned HTTP 401 \(Unauthorized\) or HTTP 500 \(Internal Server Error\) responses and failed to run successfully. Any workflows that failed during this period needed to be manually re-run after the issue was resolved. ## _Root Cause_ A recent update to Integration Service introduced a serialization and deserialization issue in how requests to external LLM providers were processed. Because of this issue, some requests to external AI providers failed, which caused workflows using BYO LLM configurations to stop running successfully. ## _Detection_ The issue was discovered through monitoring that detected an increase in failed requests related to BYO LLM connections. Because the issue affected only certain workflows and external model connections, the overall service remained available, which delayed detection. ## _Response_ Once the issue was identified, engineers investigated the failures affecting BYO LLM connections. **February 27, 2026** * **Shortly after detection** — Engineers confirmed the issue and began reverting the recent change. * A fix was deployed to restore the previous behavior for configuration handling. * Service improvements were observed as error rates began to decrease. * Engineers validated the fix by confirming that workflows connecting to external LLM providers were running successfully. * **3:40 PM UTC** — Service recovery was confirmed and all affected functionality returned to normal. Throughout the incident, customer updates were shared on the status page and monitoring continued to ensure stability. ## _Follow-Up_ We are implementing improvements to reduce the likelihood of similar incidents. _Short-term improvements_ * Add additional validation before deployments that affect external AI integrations, including serialization and deserialization handling. * Improve monitoring so issues with external model connections are detected faster. _Long-term improvements_ * Expand testing for supported external AI providers such as Vertex AI, OpenAI, and Azure OpenAI. * Introduce gradual rollouts for changes affecting critical integrations to detect issues earlier.

## Customer Impact Between 2026-02-27 06:25 UTC and 2026-02-27 14:12 UTC \(approximately 7 hours 47 minutes\), customers across multiple regions were unable to create or modify Entity definitions using few connectors through the Data Service. The Create Entity preview feature was not functioning as expected for a subset of connectors. Existing Entities capabilities in Data Explorer and activities were not affected. **Affected Connectors:** SAP C4C, Oracle NetSuite, Zendesk, HubSpot CRM, BambooHR, Zoho Desk, UiPath Data Service, QuickBooks Online, FreshDesk, DocuSign There was no data loss or long-term impact. All connections were restored after the fix was deployed. ## Root Cause A code change introduced a feature flag check for listing connections, but the base master connection list was incomplete — it was missing some connectors that previously existed in Data Service. As a result, the affected connectors did not appear when the feature flag was evaluated, preventing customers from creating or modifying Entity definitions through those connectors. This was a shallow-level code issue with no deep architectural impact. The fix involved updating the master connection list to include all previously available connectors and adjusting the feature flag accordingly. ## Detection The issue was detected at 2026-02-27 06:25 UTC via an automated alert created through the incident workflow in Rootly. The alert was acknowledged by DataFabric team within minutes. A customer-impacting incident was declared at 06:41 UTC, and the status page was created at 06:40 UTC. By 06:48 UTC, the DataFabric team confirmed the scope: Entity definition create/modify operations were restricted, while existing Entity queries and behaviour remained unaffected. ## Response * **06:25 UTC** – Issue detected and investigation started. * **06:41 UTC** – Customer-impacting incident declared. * **~07:40 UTC** – Root cause identified and fix prepared. * **~09:45 UTC** – Fix validated in pre-production environment. * **~10:20 UTC** – Deployment initiated across production regions. * **13:53 UTC** – Deployment completed across all affected regions. * **14:12 UTC** – Incident fully resolved and monitoring completed. ## Follow-Up Actions To prevent similar incidents in the future, we are implementing the following improvements: * Strengthening validation checks to ensure all supported connectors are correctly included during feature updates. * Improving pre-release verification processes for changes affecting connector configuration or visibility. * Enhancing monitoring to proactively detect unexpected connector availability issues.