UiPath Outage History

Started Mar 17, 2026, 05:08 AM UTC· resolved Mar 17, 2026, 01:20 PM UTC

1. investigating Mar 17, 2026, 05:08 AM UTC

   We are experiencing degraded service on Customer Portal affecting multiple support-related features. Affected functionality: - Customer Support Infrastructure - Viewing existing support case details and email replies - Account/Company data loading - Self-registration case status checks - File downloads linked to support cases What's working: - Authentication and login - Non-support dependent features (Knowledge Base, Community, etc.) Root cause: An upstream dependency used by Customer Portal's support Infrastructure is currently experiencing a service disruption. Next steps: Our team is actively monitoring the situation and working to restore full service as quickly as possible. No action is required from customers at this time. We will provide updates as the situation evolves.

2. investigating Mar 17, 2026, 06:43 AM UTC

   The upstream provider has identified the root cause of the disruption and is actively deploying a fix across affected instances We are seeing gradual improvement in Customer Portal functionality.

3. monitoring Mar 17, 2026, 07:51 AM UTC

   System recovery is in progress and Customer Portal features are now operational We are currently monitoring system stability and conducting final verification before confirming full resolution.

4. resolved Mar 17, 2026, 01:20 PM UTC

   The upstream dependency issue has been fully resolved. All Customer Portal services have been restored and are operating normally. We apologize for any inconvenience caused. Thank you for your patience.

5. postmortem Mar 30, 2026, 07:09 AM UTC

   ## Customer Impact **Regions Affected: Global \(all regions\)** **Services Affected:** Customer Portal - Support Cases, User/Account Team features, Knowledge Base **Timeframe:** * **Impact Start:** March 17, 2026, 9:34 am IST * **Impact End:** March 17, 2026, 11:55 am IST * **Total Duration:** ~2 hours 21 minutes **Customer Experience - Failed Operations:** * **Support Cases:** Viewing case lists/details, creating cases and follow-ups, reopening/escalating cases, sending email replies, handling attachments, and viewing dashboard stats * **User and Account Team:** Viewing UiPath contacts \(CSM, TAM, Account Owner\), updating contact flags, and accessing contact info, although cached Redis data remained temporarily available * **Knowledge Base:** Loading KB article images failed when they were not cached ## Root Cause On March 16-17, 2026, Salesforce experienced a major global service disruption affecting multiple production instances worldwide. This was a significant Salesforce outage, impacting customers globally. **Salesforce Incident:** [Trust Status](https://status.salesforce.com/incidents/20003819) Customer Portal services rely on Salesforce as the source of truth for support cases, user/contact information, and account data. As a result, the disruption to Salesforce APIs led to failures and degraded performance across all dependent functionalities. ## Detection The issue was discovered automatically through our monitoring system within 10 minutes ## Response We promptly updated our status page after confirming the upstream issue, continuously monitored recovery progress from Salesforce, and validated all dependent Customer Portal functionalities as services were restored, followed by additional checks to ensure stability. ## Follow-Up Since Salesforce was a single point of failure, there was no direct mitigation possible from our side during the outage. Our focus was therefore on timely communication, continuous monitoring, and validating end-to-end flow recovery as soon as the service was restored.

Read the full incident report →

Started Mar 15, 2026, 08:43 PM UTC· resolved Mar 15, 2026, 08:59 PM UTC

1. investigating Mar 15, 2026, 08:43 PM UTC

   We are investigating reports of an outage impacting the Web Search tool used in RPA workflows and Agents in Multiple Regions. Impact: Users may be unable to run RPA workflows or deployed/debug Agents that rely on the Web Search tool, which may cause those automations to fail. Next update: Our teams are working to understand the cause and scope and will share updates as available.

2. identified Mar 15, 2026, 08:45 PM UTC

   We have identified the cause of the outage impacting the Web Search tool used in RPA workflows and Agents in Multiple Regions and are working on a fix. Impact: Users may continue to be unable to run RPA workflows or deployed/debug Agents that rely on the Web Search tool, which may cause those automations to fail. Next update: Our focus is on restoring service as quickly as possible.

3. resolved Mar 15, 2026, 08:59 PM UTC

   The issue has been resolved. Our monitoring indicates that services are operating normally, and no further impact has been observed.

Read the full incident report →

Started Mar 13, 2026, 01:26 PM UTC· resolved Mar 13, 2026, 01:56 PM UTC

1. investigating Mar 13, 2026, 01:26 PM UTC

   We are currently investigating an issue impacting Studio Web in the Australia region. Further updates will be provided shortly.

2. monitoring Mar 13, 2026, 01:33 PM UTC

   A fix has been implemented and we are monitoring the results.

3. resolved Mar 13, 2026, 01:56 PM UTC

   The incident has been resolved, and Studio Web is now functioning normally in the Australia region.

4. postmortem Mar 18, 2026, 08:49 AM UTC

   ## Customer Impact On March 13, 2026, between approximately 13:01 and 13:55 UTC, customers using Studio Web in the Enterprise Australia environment experienced a service outage. Users encountered HTTP 503 errors and were unable to access Studio Web. The incident occurred at midnight local time in Australia \(AEDT\) or 1 PM UTC, which significantly limited customer exposure. ## Root Cause A routine change included a security hardening change that updated the internal port used by the service. During the staged deployment process, the updated port configuration was applied to the service routing layer before the running service instances were replaced with the new version. This created a mismatch: the routing layer directed traffic to the new port, but the existing service instances were still listening on the old port, making them unreachable. This was an edge case in our staged deployment tooling, which does not account for port changes between versions. The port change was validated in pre-production environments, but the specific interaction with the staged deployment process was not anticipated. ## Detection The issue was detected automatically by our monitoring systems soon after the deployment entered its validation phase. ## Response The team quickly identified the configuration mismatch and applied a mitigation by synchronizing the routing configuration with the running service instances. All services completed their updates by 13:32 UTC, restoring full functionality. The service was confirmed fully restored at approximately 13:55 UTC after a stability monitoring period. ## Follow-Up 1. Implement pre-deployment validations for detecting such configuration changes. 2. Investigate and improve the automatic failover mechanism for the Australia environment, which did not trigger as expected during this incident. 3. Add service endpoint validation to verify that traffic actually reaches service instances through the routing layer, not just that instances are healthy. 4. Develop a deployment strategy for configuration changes that affect service routing, ensuring they are applied atomically with the service update.

Read the full incident report →

Started Mar 13, 2026, 12:57 PM UTC· resolved Mar 13, 2026, 01:14 PM UTC

1. investigating Mar 13, 2026, 12:57 PM UTC

   We are currently investigating an issue impacting Studio Web in the US region. Further updates will be provided shortly.

2. monitoring Mar 13, 2026, 01:08 PM UTC

   A fix has been implemented and we are monitoring the results.

3. resolved Mar 13, 2026, 01:14 PM UTC

   This incident has been resolved.

4. postmortem Mar 18, 2026, 03:12 AM UTC

   ## Customer Impact On March 13, 2026, between 12:31 and 13:09 UTC, customers using Studio Web in the U.S. environment experienced a service outage lasting approximately 38 minutes. Users encountered HTTP 503 errors and were unable to access Studio Web during this period. The incident occurred at 11:31 am UTC, before the start of U.S. business hours, which limited the number of affected customers. Based on our analysis, a small number of customers experienced failed requests during the outage window. ## Root Cause A planned infrastructure change updated the network configuration of our enterprise U.S. production environment, changing the outbound IP address used by the service. The new IP address was not added to the access rules of a critical storage resource that the service depends on. When service instances restarted, they were unable to connect to this storage resource because the new IP address was blocked by the existing network access rules. The dependency between the environment's outbound IP and the storage resource's access rules was not tracked in the migration process, and there was no automated validation to verify that all dependent resources had been updated before the migration proceeded. ## Detection The issue was detected automatically by our monitoring systems within minutes of the service becoming unavailable. Our on-call engineering team was engaged immediately after being alerted. ## Response Our engineering team identified the root cause within 22 minutes of engagement by analyzing service logs and correlating them with the ongoing infrastructure migration. The issue was resolved at 13:06 UTC by updating the storage resource's network access rules to allow the new IP address. Full service restoration was confirmed at 13:09 UTC. Total time from first alert to confirmed resolution: 38 minutes. ## Follow-Up 1. Implement validation for such specific edge-cases before proceeding with further infrastructure changes. 2. Audit all storage resources and network-restricted dependencies across all regions to identify and remediate similar configuration gaps before resuming the migration. 3. Implement automated pre-migration validation that verifies all dependent resources have been updated with new network configurations. 4. Add dedicated monitoring for storage connectivity failures to enable faster detection of this specific failure mode.

Read the full incident report →

Started Mar 13, 2026, 11:44 AM UTC· resolved Mar 13, 2026, 11:44 AM UTC

1. resolved Mar 13, 2026, 11:44 AM UTC

   Between 2026-03-13 08:00 UTC and 2026-03-13 11:00 UTC, the Integration Service event triggers experienced partial degradation due to connectivity issues with the database. There was no data loss during this period. however, event delivery would have been delayed.

2. postmortem Mar 20, 2026, 04:31 PM UTC

   ## _Customer Impact_ Between March 13, 2026 at 11:38 am UTC and March 13, 2026 at 11:47 am UTC, a subset of customers in the Australia region may have experienced a partial degradation of event triggers. During this period, automated workflows that rely on event-based triggers may have failed to start as expected, resulting in delays or missed executions for some scheduled or real-time automation tasks. The impact was limited to customers using event-driven automation features in the Australia region. Other regions and core platform functionality remained fully operational throughout the incident. The disruption lasted for approximately nine minutes. ## _Root Cause_ As part of a routine infrastructure maintenance activity, configuration of a database was updated. While the update was successfully applied to one part of the service infrastructure, it was not propagated to a second part due to a gap in the manual deployment process. As a result, that portion of the service continued attempting to connect using an outdated configuration, causing connectivity failures that led to the degradation of Event Triggers for customers in Australia. ## _Detection_ The issue was detected automatically through UiPath internal monitoring and alerting systems, which identified anomalous behavior in the Event Triggers service and triggered alerts. A contributing factor was that the deployment process for this maintenance activity relied on manual steps, which introduced the risk of incomplete propagation across all parts of the service infrastructure. ## _Response_ The following steps were taken to investigate, mitigate, and resolve the issue: * **Detection** — Automated monitoring identified the degradation and an incident was immediately declared. * **Investigation** — The on-call engineering team began diagnosing the issue and quickly identified the root cause as a configuration mismatch introduced during the planned maintenance activity. * **Mitigation** — The affected portion of the service infrastructure was updated with the correct configuration and restarted, restoring full connectivity. * **Resolution** — The Event Triggers service was confirmed to be fully operational within approximately 9 minutes of the incident being declared. ## _Follow-Up_ UiPath is committed to preventing this class of issue from recurring. The following improvements are planned: * **Short-term:** A review of routine maintenance activities will be conducted to confirm that configuration updates have been fully and consistently applied across all components of affected services. * **Long-term — Automated deployment validation:** Configuration changes made during maintenance activities will be automatically propagated and validated across all service components, eliminating reliance on manual steps. * **Long-term — Configuration drift detection:** Monitoring will be enhanced to detect and alert on configuration mismatches across service components before they result in customer impact. * **Long-term — Improved deployment process:** Deployment procedures for maintenance activities will be updated to include explicit validation checkpoints ensuring all service components have received and acknowledged configuration updates before the activity is considered complete.

Read the full incident report →

Started Mar 12, 2026, 04:39 PM UTC· resolved Mar 12, 2026, 06:28 PM UTC

1. investigating Mar 12, 2026, 04:39 PM UTC

   We are investigating reports of degraded performance impacting Orchestrator in Canada. Our teams are working to identify the cause and will share more details as the investigation progresses.

2. investigating Mar 12, 2026, 05:33 PM UTC

   Our teams are continuing to investigate the degraded performance impacting Orchestrator in Canada. The investigation is ongoing, and we are working to identify the root cause. We will share additional updates as more information becomes available.

3. investigating Mar 12, 2026, 05:55 PM UTC

   Update: Our teams are continuing to investigate the degraded performance impacting services in Canada. The scope has expanded from Orchestrator to all services in the Canada region. The investigation is ongoing, and we are working to identify the root cause. We will share additional updates as more information becomes available.

4. monitoring Mar 12, 2026, 06:11 PM UTC

   Our teams have identified the issue causing degraded performance impacting services in the Canada region and have implemented a fix. We are currently monitoring the services to ensure stability and will share additional updates if needed.

5. monitoring Mar 12, 2026, 06:18 PM UTC

   Our teams have identified the issue causing degraded performance impacting customers accessing UiPath from the Canada region and have implemented a fix. We are currently monitoring the services to ensure stability and will share additional updates if needed.

6. resolved Mar 12, 2026, 06:28 PM UTC

   Our teams have identified and resolved the issue that was causing degraded performance impacting customers accessing UiPath from the Canada region. A fix has been implemented, and services have recovered. We will continue monitoring to ensure ongoing stability.

7. postmortem Mar 16, 2026, 07:06 AM UTC

   ## Customer Impact Customers in the **Canada region** experienced intermittent slowness and timeouts when accessing UiPath Automation Cloud services—including Orchestrator, Action Center, and asset retrieval—over a period of approximately three days. UiPath was in the process of rolling out new gateway infrastructure across regions in a phased manner. The Canada region was one of the regions receiving this rollout. Because the rollout was partial—not all regions were migrated simultaneously—customers whose traffic was routed through the Canada Central gateway were affected. Services in other regions continued to operate normally. * **Impact start**: ~March 9, 2026 16:00 UTC * **Most severe window**: March 11, 08:00–12:00 UTC—request latency at the 99th percentile reached ~5 seconds \(versus a normal baseline of ~300ms\), with over 100,000 requests exceeding five seconds in a 4-hour window * **Impact end**: March 12, 17:45 UTC * **Total duration**: ~73 hours \(intermittent\), with the most acute customer-facing degradation on March 11 During this period, affected customers experienced slow page loads \(particularly Action Center and Orchestrator\), asset retrieval timeouts, and sporadic HTTP 503 errors. The error rate remained low \(peaking at 0.2% of requests\), but latency degradation caused client-side timeouts that manifested as failures for end users. ## Root Cause Customer traffic for the Canada region passes through a regional gateway that directs each request to the correct backend service. The phased rollout began in late February, with 5% of traffic routed through the new infrastructure. Fifty percent of traffic was reached on March 5, then on March 9, all traffic was switched over to the new gateway. While monitoring the gateway during the ramp-up period, no degradation or failures were observed. When all the traffic started hitting the gateway, latency was introduced but not observed. The increase in latency caused some configured thresholds to be exceeded, compounding the issue by queuing requests and triggering restarts of routing services. Routing components were restarted with fresh, empty caches. Normally, these caches allow requests to be resolved in milliseconds. Without them, each request had to fetch routing data from slower backend sources—a process that, under the additional load of the rollout, took longer than the gateway's 5-second timeout. This created a repeating cycle: new instances started up, couldn't respond fast enough, were flagged as unhealthy and restarted — only to start again with empty caches. The cycle was made worse by the Canada Central gateway running at its minimum allocated capacity, leaving insufficient room for old and new instances to run side by side during the rollout. The net effect was that a subset of customer requests experienced delays of up to 15 seconds \(due to automatic retries\), and a small number failed outright with errors. ## Detection This issue was detected via **customer reports** on March 12 at 16:54 UTC \(8:54 am PST\). The ~3-day gap between impact start \(March 9\) and detection \(March 12\) was due to: * **The issue was latency, not outright failure.** Most requests eventually succeeded after retries, so error-rate-based monitors did not trigger. * **Synthetic monitoring for the Canada region did not detect the degradation.** The synthetic checks had timeouts long enough to absorb the 15-second delays, so they continued to report as passing. ## Response Our engineering team immediately began working on this issue upon detection through customer reports on March 12. Within 51 minutes, we resolved the incident by switching traffic back to the previous infrastructure. Services returned to normal operation immediately, and we confirmed that customers could access all services without issues. ## Follow-Up 1. **Add a cache connectivity check to the routing service startup.** New instances will verify cache readiness before accepting traffic, preventing the cold-cache cycle from occurring. 2. **Increase the minimum compute capacity** for the affected gateway cluster to ensure sufficient headroom during infrastructure rollouts. 3. **Add latency-based synthetic monitoring for the Canada region.** Current checks detect total failures—a latency threshold alert would have caught this within the first hour. 4. **Audit all regional gateway clusters** for the same capacity risk to prevent recurrence in other regions. 5. **Add anomaly-detection-based alerts for service restarts, replica set creation.** Although restarts are expected during normal operation, multiple such events in a short timeframe are anomalous and should be immediately investigated.

Read the full incident report →

Started Mar 11, 2026, 01:41 AM UTC· resolved Mar 11, 2026, 06:44 AM UTC

1. investigating Mar 11, 2026, 01:41 AM UTC

   We are investigating reports of an outage impacting the Download Attachment functionality for Maestro across multiple regions. Impact: Users may be unable to download attachments using certain Integration Service connectors. Next update: Our teams are working to understand the cause and scope and will share updates as available.

2. identified Mar 11, 2026, 02:13 AM UTC

   We have identified the issue impacting the Download Attachment functionality for Maestro across multiple regions. Impact: Users may be unable to download attachments using certain Integration Service connectors. Our teams are currently working on a hotfix to resolve the issue. Next update: We will share further updates as progress is made.

3. identified Mar 11, 2026, 03:02 AM UTC

   We have identified the issue impacting the Download Attachment functionality for Maestro across multiple regions. Impact: Users may be unable to download attachments using certain Integration Service connectors. Our teams are currently working on a hotfix to resolve the issue. Next update: We will share further updates as progress is made.

4. identified Mar 11, 2026, 04:03 AM UTC

   We have deployed the fix in the lower environments and verified that it is working as expected. We are currently in the process of deploying the fix to the production environments. We will provide the next update shortly

5. identified Mar 11, 2026, 04:59 AM UTC

   The deployment is currently in progress. We will share the next update as soon as more information becomes available

6. monitoring Mar 11, 2026, 05:59 AM UTC

   The fix has been rolled out to the following regions: Australia, Canada, India, US, UK, and EU, and has been verified. We are continuing deployment and verification in the remaining regions.

7. monitoring Mar 11, 2026, 06:13 AM UTC

   The fix has been rolled out to all regions. We will continue monitoring the incident through our monitoring systems for some time before marking it as resolved.

8. resolved Mar 11, 2026, 06:44 AM UTC

   The issue has been resolved. The fix has been fully deployed across all regions, and our monitoring systems confirm that services are operating normally.

Read the full incident report →

Started Mar 10, 2026, 06:01 PM UTC· resolved Mar 11, 2026, 08:10 AM UTC

1. investigating Mar 10, 2026, 06:01 PM UTC

   We are investigating reports of an outage impacting the Web Search tool used in RPA workflows and Agents in Multiple Regions. Impact: Users may be unable to run RPA workflows or deployed/debug Agents that rely on the Web Search tool, which may cause those automations to fail. Next update: Our teams are working to understand the cause and scope and will share updates as available.

2. identified Mar 10, 2026, 07:49 PM UTC

   We have identified the cause of the outage impacting the Web Search tool used in RPA workflows and Agents in Multiple Regions and are working on a fix. Impact: Users may continue to be unable to run RPA workflows or deployed/debug Agents that rely on the Web Search tool, which may cause those automations to fail. Next update: Our focus is on restoring service as quickly as possible.

3. monitoring Mar 11, 2026, 07:31 AM UTC

   The fix has been deployed and services have been restored. We will continue to monitor system stability before marking the incident as resolved.

4. resolved Mar 11, 2026, 08:10 AM UTC

   The issue has been resolved. Our monitoring indicates that services are operating normally, and no further impact has been observed.

5. postmortem Mar 31, 2026, 02:28 PM UTC

   **Customer Impact** Between 2026-03-10 13:54 UTC and 2026-03-11 08:00 UTC, the web Search tool experienced a service disruption. During this window, automated Agents and RPA workflows requiring real-time web search functionality encountered execution failures. **Root Cause** The disruption was caused by an upstream API quota exhaustion triggered by an atypical spike in request volume. The specific legacy endpoint used for this service maintains a fixed, inelastic daily throughput limit. Due to the provider’s deprecation schedule, standard scalability options are currently restricted. This forced a shift from automated infrastructure adjustments to manual traffic management to maintain service stability during the transition period. **Resolution** To restore service and prevent a recurrence, our engineering team deployed a multi-tenant rate-limiting policy. This ensures that high-volume requests from a single source cannot impact global service availability. Service was fully restored once the upstream provider’s daily telemetry window was reset. **Follow-Up Actions** * **Service Migration:** Since the current provider is deprecating this API, we are accelerating the transition to a more scalable, high-throughput web search alternative to ensure elastic capacity. * **Granular Governance:** Permanent implementation of per-organization request caps to ensure fair resource distribution and prevent individual workflow spikes from impacting the broader user base.

Read the full incident report →

Started Mar 10, 2026, 04:00 PM UTC· resolved Mar 10, 2026, 04:00 PM UTC

1. resolved Mar 10, 2026, 06:20 PM UTC

   On March 10, 2026, between 16:16 and 16:36 UTC, some customers experienced difficulty accessing Studio Web. During this period, our monitoring systems detected that the service was temporarily unavailable. Our investigation shows that a routine deployment activity occurred around the same time and the service also experienced a short failover event. These combined conditions contributed to a brief interruption in availability. The service recovered automatically within minutes, and access to Studio Web was fully restored without manual intervention. Impact Customers may have experienced temporary inability to access Studio Web during the time window above. Current Status The service is operating normally.

2. postmortem Apr 17, 2026, 08:48 AM UTC

   ## Customer Impact On March 10, 2026, between 16:16 and 16:36 UTC, a small subset of customers in the Europe region were unable to access Studio Web. During this approximately 20-minute window, attempts to load Studio Web returned errors or routed users to a service-unavailable page. Some customers experienced a longer perceived outage — up to roughly 45 minutes — because the service-unavailable page did not automatically recover once the service was restored. The impact was limited to Studio Web for a small subset of customers in the Europe region. Other UiPath services and regions were not affected. ## Root Cause A routine deployment introduced a security hardening update that changed the internal network port Studio Web listens on, along with how our internal routing layer forwards traffic to Studio Web's service components. During our staged deployment process, the routing update was applied while some service instances were still running the previous configuration. The resulting mismatch caused production traffic to be sent to a pathway that was no longer accepting connections, producing service-unavailable errors. A compounding factor was infrastructure capacity pressure in the shared production environment at the time of the deployment, which delayed the provisioning of replacement service instances and extended the recovery window. ## Detection The incident was detected within approximately 3 minutes of onset through our automated monitoring, which continuously checks Studio Web availability from multiple geographic locations. A subsequent alert confirmed that an automatic failover to our secondary environment had been triggered. The on-call engineering team engaged within 5 minutes of the first alert and correlated the disruption with the in-progress deployment. ## Response Upon detection, the on-call team verified that the deployment was progressing through its staged rollout and determined that it would self-recover as new service instances came online. No manual rollback was required. The service recovered automatically within minutes, and access to Studio Web was fully restored without manual intervention by 16:36 UTC. Customers who had been routed to the service-unavailable page were advised to reload Studio Web to regain access. ## Follow-Up To prevent similar incidents and reduce customer-facing impact from comparable conditions, we are implementing the following improvements: 1. We have updated our deployment configuration so that internal service routing changes are coordinated with service instance updates, preventing the specific mismatch that caused this incident. 2. We have tuned our deployment infrastructure chart to avoid service instance starvation when the shared cluster is under memory pressure, so that rollouts proceed reliably even under capacity constraints. 3. We are adding auto-recovery to the service-unavailable page so that when Studio Web is restored, the page redirects customers back to the application automatically rather than requiring a manual reload. 4. We have investigated and addressed a limitation in our automatic failover that caused only a small fraction of production traffic to route to the secondary environment during the outage. Failover is now configured to fully mitigate similar primary-environment disruptions in the future.

Read the full incident report →

Started Mar 10, 2026, 03:46 PM UTC· resolved Mar 10, 2026, 09:54 PM UTC

1. investigating Mar 10, 2026, 03:46 PM UTC

   We are investigating reports of an outage impacting Maestro Agentic Process loading in Studio Web for Maestro in Multiple Regions. Impact: Users may be unable to load the Maestro Agentic Process in Studio Web. Next update: Our teams are working to understand the cause and scope and will share updates as available. Additional notes: We’re seeing a rise in errors when loading the Maestro Agentic Process in Studio Web. Clearing the browser cache may temporarily resolve the issue while we work on a long term fix.

2. investigating Mar 10, 2026, 04:42 PM UTC

   We are continuing to investigate reports of an outage impacting Maestro Agentic Process loading in Studio Web for Maestro in Multiple Regions. Impact: Users may be unable to load the Maestro Agentic Process in Studio Web. Next update: Our teams are continuing to investigate the cause and scope and will share updates as available. Additional notes: We’re seeing a rise in errors when loading the Maestro Agentic Process in Studio Web. Clearing the browser cache may temporarily resolve the issue while we work on a long term fix.

3. investigating Mar 10, 2026, 05:39 PM UTC

   We are continuing to investigate reports of an outage impacting Maestro Agentic Process loading in Studio Web for Maestro in Multiple Regions. Impact: Users may be unable to load the Maestro Agentic Process in Studio Web. Next update: Our teams are continuing to investigate the cause and scope and will share updates as available. Additional notes: We’re seeing a rise in errors when loading the Maestro Agentic Process in Studio Web. Clearing the browser cache may temporarily resolve the issue while we work on a long term fix.

4. investigating Mar 10, 2026, 06:36 PM UTC

   We are continuing to investigate reports of an outage impacting Maestro Agentic Process loading in Studio Web for Maestro in Multiple Regions. Impact: Users may be unable to load the Maestro Agentic Process in Studio Web. Next update: Our teams are continuing to investigate the cause and scope and will share updates as available. Additional notes: We’re seeing a rise in errors when loading the Maestro Agentic Process in Studio Web. Clearing the browser cache may temporarily resolve the issue while we work on a long term fix.

5. identified Mar 10, 2026, 09:25 PM UTC

   We are continuing to investigate reports of an outage impacting Maestro Agentic Process loading in Studio Web across multiple regions. Impact: Users may be unable to load the Maestro Agentic Process in Studio Web. Current Status: We have identified the issue and are currently implementing a fix. Workaround: Clearing the browser cache may temporarily resolve the issue while we work toward a permanent resolution. Next Update: Our teams are actively working on the fix and will share further updates as they become available.

6. resolved Mar 10, 2026, 09:54 PM UTC

   The outage has been resolved and Maestro, Studio Web is fully operational. Impact: No ongoing user impact.

7. postmortem Apr 17, 2026, 05:58 AM UTC

   ### 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.

Read the full incident report →

Started Mar 10, 2026, 12:39 PM UTC· resolved Mar 10, 2026, 02:39 PM UTC

1. investigating Mar 10, 2026, 12:39 PM UTC

   We are currently investigating reports of an issue in DataFabric in the Europe region. Impact: Customers using Data Fabric in the EU Production Automation Cloud may experience intermittent degraded performance and failed requests Our teams are actively working to identify the cause and assess the scope of the issue. Further updates will be shared as soon as more information becomes available.

2. monitoring Mar 10, 2026, 01:43 PM UTC

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

3. resolved Mar 10, 2026, 02:39 PM UTC

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

4. postmortem Mar 16, 2026, 07:39 AM UTC

   ## _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.

Read the full incident report →

Started Mar 10, 2026, 11:41 AM UTC· resolved Mar 10, 2026, 01:12 PM UTC

1. investigating Mar 10, 2026, 11:41 AM UTC

   We are currently investigating reports of an outage affecting AI Center accessibility in the India region. Impact: Users may be unable to access AI Center Our teams are actively working to identify the cause and assess the scope of the issue. Further updates will be shared as soon as more information becomes available.

2. monitoring Mar 10, 2026, 12:35 PM UTC

   We have identified the root cause of the issue affecting AI Center accessibility in the India region. A fix has been deployed and the service is recovering. Current status: We are monitoring the system to ensure stability and full recovery. Further updates will be shared soon

3. resolved Mar 10, 2026, 01:12 PM UTC

   The issue has been resolved. A fix was deployed and the system has remained stable during the monitoring period.

4. postmortem Mar 16, 2026, 04:14 PM UTC

   ## _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™.

Read the full incident report →

Started Mar 09, 2026, 04:41 PM UTC· resolved Mar 09, 2026, 08:41 PM UTC

1. investigating Mar 09, 2026, 04:41 PM UTC

   We are investigating reports of an outage impacting the Web Summary tool for Agents in Multiple Regions. Impact: Users may be unable to run deployed or debug Agents that rely on the Web Summary tool, causing those workflows to fail. Next update: Our teams are working to understand the cause and scope and will share updates as available.

2. investigating Mar 09, 2026, 05:12 PM UTC

   We are investigating reports of an outage impacting the Web Summary tool used in RPA workflows and Agents in Multiple Regions. Impact: Users may be unable to run RPA workflows or deployed/debug Agents that rely on the Web Summary tool, which may cause those automations to fail. Next update: Our teams are working to understand the cause and scope and will share updates as available.

3. identified Mar 09, 2026, 05:46 PM UTC

   We have identified the cause of the outage impacting the Web Summary tool for RPA workflows and Agents in Multiple Regions and are working on a fix. Impact: Users may continue to be unable to run RPA workflows or deployed/debug Agents that rely on the Web Summary tool, which may cause those automations to fail. Next update: Our focus is on restoring service as quickly as possible.

4. identified Mar 09, 2026, 06:46 PM UTC

   We have identified the cause of the outage impacting the Web Summary tool for RPA workflows and Agents in Multiple Regions and are continuing to work on a fix. Impact: Users may continue to be unable to run RPA workflows or deployed/debug Agents that rely on the Web Summary tool, which may cause those automations to fail. Next update: Our teams are actively working to restore service and will share updates as progress is made.

5. identified Mar 09, 2026, 07:36 PM UTC

   We have identified the cause of the outage impacting the Web Summary tool for RPA workflows and Agents in Multiple Regions and are continuing to work on a fix. Impact: Users may continue to be unable to run RPA workflows or deployed/debug Agents that rely on the Web Summary tool, which may cause those automations to fail. Next update: Our teams are actively working to restore service and will share updates as progress is made.

6. monitoring Mar 09, 2026, 08:37 PM UTC

   We have identified the cause of the outage impacting the Web Summary tool for RPA workflows and Agents across multiple regions and have implemented a fix. Our teams are currently monitoring the environment to ensure the fix is stable and that services continue to operate normally. Next update: We will continue monitoring and provide further updates as we confirm sustained service stability.

7. resolved Mar 09, 2026, 08:41 PM UTC

   The issue impacting the Web Summary tool for RPA workflows and Agents across multiple regions has been resolved. Root cause was identified and a fix has been successfully implemented. Services have been restored and users should now be able to run RPA workflows and deployed or debug Agents that rely on the Web Summary tool without failure. Thank you for your patience while our teams worked to resolve the issue.

8. postmortem Mar 18, 2026, 11:54 PM UTC

   **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.

Read the full incident report →

Started Mar 09, 2026, 01:21 PM UTC· resolved Mar 10, 2026, 01:15 PM UTC

1. identified Mar 09, 2026, 01:21 PM UTC

   We have identified the cause and are working on mitigation. Impact: Some users may experience issues when executing processes using target execution bindings. Additional updates will be provided as we move toward resolution. Affected Regions: - Europe - US - Japan - Australia - Canada - Singapore - India - UK - Switzerland - Delayed US - Delayed EU

2. identified Mar 09, 2026, 01:27 PM UTC

   We have identified the cause and are working on mitigation. Impact: Some users may experience issues when executing any process using target execution bindings. Additional updates will be provided as we move toward resolution. Affected Regions: - Europe - US - Japan - Australia - Canada - Singapore - India - UK - Switzerland - Delayed US - Delayed EU

3. identified Mar 09, 2026, 02:26 PM UTC

   Our team is actively working toward a resolution. We will provide the next update as soon as more information becomes available.

4. identified Mar 09, 2026, 07:34 PM UTC

   A fix has been developed and deployed to our lower environments for validation. We are currently testing the changes to ensure stability before proceeding with a wider rollout. We plan to deploy the fix across production environments once validation is complete. Additional updates will be provided as we make progress toward full resolution.

5. monitoring Mar 10, 2026, 10:45 AM UTC

   The fix has been successfully applied in the following regions and is functioning as expected: European Union, United States, India, Australia, Canada, UK, Switzerland, Delayed-US, and UAE. We are in the process of rolling out the changes to the remaining regions and validating them

6. resolved Mar 10, 2026, 01:15 PM UTC

   The issue has been resolved. A fix was deployed to the remaining regions and the system has remained stable during the monitoring period.

7. postmortem Mar 16, 2026, 09:36 AM UTC

   ## _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.

Read the full incident report →

Started Mar 06, 2026, 04:06 PM UTC· resolved Mar 06, 2026, 04:32 PM UTC

1. investigating Mar 06, 2026, 04:06 PM UTC

   Agent traces are missing for some customers and we are investigating.

2. investigating Mar 06, 2026, 04:08 PM UTC

   Agent traces are not appearing for some customers and we are investigating.

3. monitoring Mar 06, 2026, 04:29 PM UTC

   Mitigation has been applied and performance is improving for the issue that impacted traces in Agents across US. We are monitoring closely to ensure stability.

4. resolved Mar 06, 2026, 04:32 PM UTC

   The issue has been resolved and Agents performance has returned to expected levels after degraded performance impacted traces in US. Impact: No ongoing user impact.

Read the full incident report →

Started Mar 05, 2026, 12:38 AM UTC· resolved Mar 05, 2026, 01:01 AM UTC

1. monitoring Mar 05, 2026, 12:38 AM UTC

   Affected Regions: - Europe - US - Japan - Australia - Canada - Singapore - Delayed US - Delayed EU - India - UK - Switzerland

2. resolved Mar 05, 2026, 01:01 AM UTC

   Affected Regions: - Europe - US - Japan - Australia - Canada - Singapore - Delayed US - Delayed EU - India - UK - Switzerland

3. postmortem Apr 20, 2026, 07:37 PM UTC

   ## 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.

Read the full incident report →

Started Mar 03, 2026, 08:29 PM UTC· resolved Mar 03, 2026, 11:36 PM UTC

1. investigating Mar 03, 2026, 08:29 PM UTC

   Affected Regions: - Europe - India - UK - Switzerland

2. identified Mar 03, 2026, 09:36 PM UTC

   Identified issues and team is working towards resolution.

3. identified Mar 03, 2026, 09:37 PM UTC

   Identified issues and team is working towards resolution.

4. monitoring Mar 03, 2026, 10:31 PM UTC

   A fix is deployed and we are monitoring the fix.

5. resolved Mar 03, 2026, 11:36 PM UTC

   A fix is deployed and we are monitoring the fix.

6. postmortem Mar 05, 2026, 11:59 AM UTC

   ## 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.

Read the full incident report →

Started Feb 27, 2026, 04:33 PM UTC· resolved Feb 27, 2026, 05:12 PM UTC

1. monitoring Feb 27, 2026, 04:33 PM UTC

   Starting at 2/26/2026 1:30 PM UTC to 2/27/2026 3:40 PM UTC We experienced an incident affecting Integration Service connectors used by the AI Trust Layer “Bring Your Own” (BYO) feature. Customers using BYO LLM/LLM Configurations to power Agents, GenAI Activities, or other agentic products may have encountered workflow failures during the impacted period. The issue occurred because we were unable to retrieve required connection details at runtime, resulting in failed requests to customer-configured external models. The issue has been identified and resolved. Service is fully restored, though workflows that failed during the incident window may need to be re-run. We continue to monitor the system to ensure stability.

2. resolved Feb 27, 2026, 05:12 PM UTC

   Starting at 2/26/2026 1:30 PM UTC to 2/27/2026 3:40 PM UTC We experienced an incident affecting Integration Service connectors used by the AI Trust Layer “Bring Your Own” (BYO) feature. Customers using BYO LLM/LLM Configurations to power Agents, GenAI Activities, or other agentic products may have encountered workflow failures during the impacted period. The issue occurred because we were unable to retrieve required connection details at runtime, resulting in failed requests to customer-configured external models. The issue has been identified and resolved. Service is fully restored, though workflows that failed during the incident window may need to be re-run. We continue to monitor the system to ensure stability.

3. postmortem Mar 18, 2026, 08:00 AM UTC

   ## _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.

Read the full incident report →

Started Feb 27, 2026, 06:40 AM UTC· resolved Feb 27, 2026, 02:12 PM UTC

1. investigating Feb 27, 2026, 06:40 AM UTC

   We are currently investigating the issue Affected Regions: - Europe - US - Japan - Australia - Canada - Singapore - Delayed US - Delayed EU - India - UK - Switzerland - UAE

2. identified Feb 27, 2026, 07:42 AM UTC

   We have identified the scope of the issue. The impact is limited to the Create Entity preview feature. This action is currently not functioning as expected for a subset of connectors. Affected connectors: • SAP C4C • Oracle NetSuite • Zendesk • HubSpot CRM • BambooHR • Zoho Desk • UiPath Data Fabric • QuickBooks Online • FreshDesk • DocuSign

3. identified Feb 27, 2026, 08:20 AM UTC

   We have identified the scope of the issue. The impact is limited to the Create VDO Entity preview feature. This action is currently not functioning as expected for a subset of connectors.

4. identified Feb 27, 2026, 09:24 AM UTC

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

5. identified Feb 27, 2026, 10:23 AM UTC

   We have identified a fix and are actively validating it in our testing environments. We will continue to provide updates as we make progress.

6. identified Feb 27, 2026, 11:18 AM UTC

   We are continuing to validate the fix in our testing environments. We will provide further updates as progress is made.

7. identified Feb 27, 2026, 12:20 PM UTC

   We have completed validation of the fix in our testing environments and will begin rolling it out shortly.

8. monitoring Feb 27, 2026, 01:58 PM UTC

   A fix has been implemented and we are monitoring the results.

9. resolved Feb 27, 2026, 02:12 PM UTC

   The incident has been fully resolved. We identified that a recent update unintentionally caused some previously available connections to not appear. The issue has been corrected, and all connections are now restored. There was no data loss or long-term impact. Thank you for your patience.

10. postmortem Mar 03, 2026, 03:06 PM UTC

    ## 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.

Read the full incident report →

Started Feb 25, 2026, 06:47 PM UTC· resolved Feb 25, 2026, 09:19 PM UTC

No vendor updates were posted for this incident.

Read the full incident report →

Started Feb 24, 2026, 06:15 PM UTC· resolved Feb 24, 2026, 08:38 PM UTC

No vendor updates were posted for this incident.

Read the full incident report →

Started Feb 24, 2026, 01:42 PM UTC· resolved Feb 24, 2026, 01:42 PM UTC

No vendor updates were posted for this incident.

Read the full incident report →

Started Feb 24, 2026, 01:58 AM UTC· resolved Feb 24, 2026, 04:33 AM UTC

No vendor updates were posted for this incident.

Read the full incident report →

Started Feb 23, 2026, 04:10 PM UTC· resolved Feb 24, 2026, 05:32 AM UTC

No vendor updates were posted for this incident.

Read the full incident report →