Uipath outage history

We are currently investigating an issue impacting the availability of insights and automation ops services. Our team is actively assessing the situation to identify the underlying cause and determine the necessary steps to restore normal operations. Further updates will be provided as more information becomes available.

The issue with Automation Ops has been resolved. We are currently waiting for the Insights service issue to be mitigated. Further updates will be shared as they become available.

Insights service in Singapore, Japan, Switzerland, Canada, India, UK, Europe, United States, UAE, South Korea & Australia region is fixed and we are applying fix on other regions

The issue has been resolved, and all services are now operating normally.

Between 20:42 and 21:19 UTC on October 23, some Orchestrator customers in Europe saw slow responses and intermittent errors. This included robot calls to get assets, process queue items and report job status. Some unattended jobs may have failed during this time. The cause was a sudden increase in load that reached the database’s resource limits. We added database capacity, and performance has been back to normal since 21:19 UTC. Customers whose jobs failed in this window may need to restart them.

We have identified an issue affecting IXP for customers hosted in the Australia region. Since 10:24 UTC, requests that use the Gemini 2.5 Flash model are failing in the region. Other models are not affected. Customer data continues to be processed only within Australia. We are working with Google to restore service

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

Following initial recovery, the service has degraded again. We are investigating and working towards a resolution. We will provide further updates as they become available.

We've contacted Google Support, and they've started investigating on their end. We'll keep monitoring and share updates as we have them.

We are observing improvements on Gemini 2.5 Flash traffic. We are monitoring a possible fix from Google.

Issue is resolved from Google.

## Customer impact Between October 22, 2026 at 10:24 am UTC and October 22, 2026 at 6:04 pm UTC, document processing requests that used Gemini 2.5 Flash in the Australia region failed with capacity errors. The impact lasted approximately 7 hours and 40 minutes. A subset of customers using document extraction workflows in that region were affected. During a temporary in-region fallback attempt, some extraction requests recovered briefly, but word-level attribution and generated page text were degraded until the fallback also began failing. ## Root cause The root cause was a provider-side regional network disruption during concurrent maintenance. This caused severe bandwidth throttling in the provider's model-serving environment, which prevented the backend systems from loading the model data needed to serve Gemini 2.5 Flash and Gemini 3.5 Flash requests reliably in the affected region. ## Detection The issue was detected through automated alerting that identified rate-limiting errors on Gemini 2.5 Flash in the Australia region. Our engineering team confirmed through telemetry that affected requests were failing consistently and began coordinating a response. ## Response At 1:40 pm UTC, we routed affected Gemini 2.5 Flash traffic to Gemini 3.5 Flash within the same region to preserve data residency. Initial telemetry showed no capacity errors after that change, but by 2:10 pm UTC, Gemini 3.5 Flash was also returning capacity errors, so the fallback was no longer viable. At 2:05 pm UTC, we adjusted related document processing paths so attribution and page-text generation would use the same in-region fallback; that adjustment completed at approximately 2:09 pm UTC. After the fallback also failed, we reverted the routing change, and by 4:28 pm UTC traffic was back on the expected Gemini 2.5 Flash path. At 5:38 pm UTC, telemetry showed improving Gemini 2.5 Flash success rates. From 6:04 pm UTC onward, no further capacity errors were observed, and subsequent requests succeeded. ## Follow up 1. Complete the reserved model capacity assessment for the affected region using the observed traffic patterns 2. Evaluate retry and backoff behavior in document processing clients to reduce retry amplification during provider-side capacity failures.

Since approximately 11:17 UTC, customers across multiple regions have experienced issues with UiPath Agents and Solutions Management. New jobs may remain in Pending status, and running agents may experience delays when processing escalations or waiting for tool results. We are investigating the issue and working toward a resolution.

The issue has been mitigated. We are monitoring the affected services across regions to ensure stability and confirm that job starts and solution deployments are functioning normally.

This incident has been resolved. Between 11:15 and 12:45 UTC on October 15, an internal configuration issue prevented some events from being delivered between UiPath services across multiple regions. The issue was resolved by rolling back the change, and new activity is being processed normally. Some work initiated or in progress during this window may require attention: - Agents: Agents waiting on Action Center tasks or automation tool results may remain stuck. Jobs started from Orchestrator may also appear stuck or time out. - Maestro: Processes waiting on user tasks may not have resumed after task completion. - Apps: Queue item statuses may be outdated, and actions triggered by queue item completion may not have run. - Autopilot for Everyone: Conversations waiting for automation results may remain stalled. - Document Understanding and Context Grounding: Automations and agents waiting for extraction, validation, or indexing may remain suspended. - Integration Service: Connector events may not have triggered the expected processes or notifications. - Solutions and Studio Web: Solution installs, uninstalls, publishes, deployments, and validations initiated during this window may have failed or timed out. Retrying these operations may resolve the issue. We apologize for the disruption and thank you for your patience.

**Customer impact** On October 15, 2026, from 11:15 to 12:50 UTC (about 1 hour and 35 minutes), some events exchanged between UiPath cloud services were not delivered. Customers in all commercial cloud regions were affected. During this window: - New agent runs could stay in Pending status. Running agents waiting on a tool result, a human escalation, document extraction, or context grounding might not resume. - Conversational agents and Autopilot for Everyone conversations that started an automation might not have received its result. - Maestro process instances waiting on a user task might not have moved forward after the task was completed, and processes triggered by Integration Service connector events might not have started. - Apps showing or reacting to queue item status could show outdated information. - Solution installs, uninstalls, publishes, and deployments could fail or time out. - Some user, group, and folder changes made in the window might not have propagated to all services. Work started after 12:50 UTC was not affected. Robot job execution, queues, and triggers handled inside Orchestrator kept working normally. **Root cause** We were moving the delivery of internal service configuration to a new mechanism, a change intended to have no effect on customers. When this change was applied to the event delivery service, the configuration it produced was missing a required value. Without it, the service treated several product integrations as turned off and silently stopped delivering their events. Because the change reached all production regions at the same time, every region was affected. **Detection** The issue was detected at 11:51 UTC, about 35 minutes after impact began, when monitoring alerted on agent jobs remaining in Pending status. Reports of solution deployments timing out followed, and an incident was declared at 12:12 UTC. **Response** Following the first detection at 11:51 UTC, the configuration change was identified and a rollback was started at 12:00 UTC. An initial rollback at 12:14 UTC did not fully restore delivery. The team then stopped the new configuration delivery process and restored the previous configuration. Event delivery began recovering at 12:40 UTC, and full recovery across all regions was confirmed at 12:50 UTC. Where possible, we replayed missed events so that affected work could continue. **Follow up** 1. The new configuration delivery process has been paused for the affected service and will stay paused until the configuration is generated correctly. 2. Validate configuration produced by the new delivery mechanism for required values before it is applied to any environment. 3. Roll out changes to configuration delivery progressively across regions instead of to all regions at once. 4. Improve our monitoring to detect within minutes when events stop being delivered to a product integration that normally receives them. 5. Improve our ability to recover and redeliver events missed during a disruption.

Some customers in the US region experienced delays in robot log ingestion, with increased activity observed between approximately 11:20 and 11:45 UTC. The issue has been resolved, and log ingestion has returned to normal. Thank you for your patience.

## Customer impact Between approximately October 15, 2026 at 11:20 pm UTC and approximately October 15, 2026 at 11:45 pm UTC, some customers in the US East region experienced delays in robot log ingestion in UiPath Orchestrator. Robot logs were not up to date during the affected period. The impact lasted approximately 20 minutes. ## Root cause During the incident, 2 of the 13 service instances handling robot log ingestion were observed failing to connect to the event ingestion service. Only requests to the event ingestion service were failing, and only on those two instances. This caused some robot log ingestion requests to not complete successfully, resulting in delayed log data for affected customers. The root cause of why only those two instances lost connectivity to the event ingestion service was not determined during the incident. The team committed to a post-incident review of logs from the affected instances to identify the underlying cause. We believe it to be an unreported infrastructure issue from our cloud provider. ## Detection The issue was detected through an automated alert at approximately 11:33 pm UTC on October 15, 2026, and confirmed through telemetry showing exceptions from the two affected service instances. ## Response After detection, telemetry confirmed that only two service instances were generating exceptions. Responders removed those two unhealthy instances from service, and replacement instances started automatically. Within approximately 20 minutes of the first alert — by approximately 11:53 pm UTC — telemetry indicated recovery and synthetic monitoring checks were passing. A broader restart of all service instances was considered but not performed, as the team determined it should not proceed without first understanding the root cause. ## Follow up 1. A post-incident review of logs from the affected service instances revealed the issue was infrastructure related, and we are following up with out cloud infrastructure provider for more details. 2. An update will be posted if the investigation yields further findings.

Starting with 6:50 UTC we have experienced a global outage that has affected the loading of apps and coded apps all regions except for India and UK. Outage has been resolved and the services are fully operational. Impact: No ongoing user impact.

Starting with 6:50 UTC we have experienced a global outage that has affected the loading of apps and coded apps all regions except for India and UK. Outage has been resolved and the services are fully operational. Impact: No ongoing user impact.

## Customer impact Between 06:38 UTC and 07:21 UTC on October 14, 2026, a portion of requests to UiPath Apps, Coded Apps, and solutions that depend on them failed in eleven regions: Europe, United States, Community, Japan, Singapore, Australia, Canada, South Korea, Switzerland, UAE, and the delayed US environment. The India and United Kingdom regions were not affected. About 2 percent of requests failed overall, between 0.6 and 5 percent depending on the region. Affected users saw applications fail to load, requests return server errors, or slow responses. In regions where service pods had to be restarted, Apps was unreachable for up to about eight minutes. Response times were back to normal in every region by 07:40 UTC. Most users of already running published apps noticed little or nothing. App definitions are cached in the browser for up to 24 hours, app data comes from Data Service and Orchestrator rather than this database, and the service kept using the database connections it already held. The requests that failed were those needing a new database connection: opening the designer or the apps list, loading an app not yet cached, downloading documents and images stored in Apps, and saving or publishing. ## Root cause At 06:38 UTC, while database access was being set up for a new regional deployment, the password of the database user that the Apps service uses was changed. That user is shared by the production database clusters of all affected regions, so the change applied to all of them at once. The running services still held the previous password and could no longer open new database connections. The India and United Kingdom regions do not use this credential and were not affected. The change was meant to create a separate database user for the new region. Instead, the password of the existing user that all regions share was changed. Our change process for database credentials did not clearly separate creating a new credential from modifying an existing one, and it did not require a check of how many clusters and regions a credential change would affect. Combined with a single database user being shared across regions, this allowed a change intended for one region to cause a multi-region outage. ## Detection Our internal monitoring raised the first alert at 06:41 UTC, three minutes after the first failures, and alerts for every affected region followed by 06:46 UTC. At 06:50 UTC the on-call engineer confirmed that every production cluster was being refused by its database and started the incident process. ## Response At 07:05 UTC the previous password was restored and authentication failures stopped everywhere. Most regions reconnected automatically. In the regions that did not, the service pods were restarted or redeployed: Delayed US at 07:21 UTC and Switzerland by 07:30 UTC. Request failures stopped at 07:21 UTC, response times were back to baseline by 07:40 UTC, and we continued monitoring until the incident was resolved at 07:43 UTC. ## Follow up To prevent this from happening again, we are: - Introducing a defined procedure for creating and rotating database credentials, with a pre-change review that states which clusters and regions share the credential, and a staged rollout that is verified in one region before it is applied more widely. - Moving to separate, least-privilege database users for each region, so that a change in one region cannot affect another. - Automatically declaring an incident and paging the database owners when the same database error is detected in several regions at once, instead of relying on manual escalation from individual regional alerts. - Enabling services to pick up updated database credentials without a restart, and to reconnect faster after an authentication failure.

We are currently investigating an outage affecting UiPath Cloud services across multiple regions. Users are unable to access services hosted in the affected regions. Next update: Additional information will be shared as it becomes available.

We are continuing to investigate this issue.

A fix has been implemented and we are monitoring the results. The issue was limited to Document Understanding, Computer Vision, Semantic Proxy, Autopilot Studi, IXP. We will share another update once the services have fully recovered.

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

This incident has been resolved following the renewal of the expired SSL certificate that affected several ML-dependent services, including IXP, Document Understanding, Computer Vision, Semantic Proxy and Autopilot for Developers. Service recovery has progressed across the affected regions, and automated alerts have been configured to help detect certificate expiry in advance and prevent similar disruptions in the future. Thank you for your patience and understanding.

## Customer Impact Between 13:37 and 14:40 UTC on October 13, 2026, customers across multiple regions were unable to use IXP Unstructured Documents, IXP Communications Mining and Document Understanding. Computer Vision and Autopilot for Developers features that depend on the same machine learning services also failed. Affected customers saw requests fail with "500 Internal Server Error" responses or time out, IXP projects that would not open, and Computer Vision activities failing in running automations. Service was disrupted for approximately 1 hour. No customer data was lost. ## Root Cause The incident was caused by an expired security certificate used to establish secure connections to these services. The certificate is renewed by an automated process. That process was no longer executing successfully and the failures did not raise an alert, so the certificate was not replaced before it expired. Secure connections to the affected services were rejected from 13:37 UTC. ## Detection Automated monitoring began alerting on errors and missing traffic at 13:40 UTC, and the incident was declared at 13:54 UTC. The expired certificate was identified at 14:00 UTC, and the first status page update was posted at 14:03 UTC. No alert warned that the certificate was approaching expiry, and the repeated failures of the automated renewal were not reported to the owning team, so the problem was only detected once customers were affected. ## Response At 14:06 UTC the team confirmed that the certificate had expired because the automated renewal had been failing. At 14:18 UTC a new credential was issued for the renewal process. The renewal was started manually at 14:19 UTC and completed at 14:33 UTC, and by 14:37 UTC every customer-facing endpoint had been verified to serve the renewed certificate. Traffic returned to normal levels by approximately 14:40 UTC. After a period of monitoring, the incident was resolved at 15:19 UTC. ## Follow-Up To help prevent similar incidents in the future, we are making the following improvements: - Alert well in advance of any of these certificates approaching expiry. - Notify the owning team whenever the automated renewal fails. - Add checks that alert as soon as secure connections to these services fail. - Strengthen ownership of the certificate renewal process and the credentials it relies on.

We are investigating issue where robot execution logs are not showing up in Orchestrator. we are working to determine the full scope and root cause.

This issue has been resolved. Robot execution logs are syncing and are visible in Orchestrator again for Japan Orchestrator. Thank you for your patience.

## Customer impact Between approximately 07:00 UTC on 9 Oct 2026 and 10:45 UTC on 13 Oct 2026, about 6% of robot log entries for customers in the Japan region did not appear in Orchestrator. Job execution and all other Orchestrator functionality were not affected. Missing entries became visible in Orchestrator after the issue was fixed. ## Root cause Robot logs are placed on a queue split into 32 partitions, and an ingestion service reads each partition and stores the logs for Orchestrator. On October 9, the ingestion service in the Japan region stopped reading from 2 of the 32 partitions without reporting an error. Logs on those partitions were kept in the queue but not stored, so they did not appear in Orchestrator. Our monitoring checked the service as a whole, not each partition, so the issue was not detected automatically. ## Detection The issue was detected through customer reports. We declared an incident at 10:13 UTC on October 13 and posted a status page notification at 10:32 UTC. ## Response We restarted the ingestion service at approximately 10:41 UTC, and it resumed reading all partitions. The logs held in the queue were then processed and became visible in Orchestrator. The incident was resolved at 10:57 UTC. ## Follow up * We are adding monitoring that alerts us when any single partition stops being read, so this kind of issue is detected within minutes.

We are investigating reports of an outage impacting HITL task creation failures for Maestro in US. Impact: Users may be unable to create HITL tasks. Next update: Our teams are working to understand the cause and scope and will share updates as available.

We have identified the cause for an outage impacting HITL task creation for Maestro in US and are working to mitigate the issue. Impact: Users may be unable to create HITL tasks. Next update: Our teams are working to mitigate the issue and will share updates as available.

We are rolling out fix for an outage impacting HITL task creation for Maestros with HITL task SLA timers configured in US and are working to mitigate the issue. Impact: Users may be unable to create HITL tasks within Maestros with HITL task SLA timers configured. Next update: Our teams are working to mitigate the issue and will share updates as available.

The fix for the issue impacting HITL task creation for Maestro with HITL task SLA timers configured in US has been fully rolled out. HITL task creation has returned to normal.

## Customer impact On 2026-10-05 between 9.30 PM UTC - 2026-10-07 3.30 AM UTC, Maestro BPMN and Case customers using HITL nodes with a configured Task Timer saw failures of their debug and production instances at the HITL stage, with 4xx . About 30 such instances across customers across US and Europe were identified, that were blocked with no workaround. ## Root cause Configuring a task SLA requires an object including the start and end criteria, the timer of the SLA, and the outcome on SLA breach. Customers configure that on the Maestro designer on the HITL node. The outcome was mistakenly kept non-mandatory on the design surface, even though an SLA configuration without an outcome isn't persisted and doesn't make business sense. The Action Center backend team had added a validation to throw a bad request (400) in case of a non null SLA object with a missing outcome. This ended up impacting customers who had added the Start/End criteria on the node but not configured an outcome. Instances that were previously running failed with 400s, and were unable to resume ## Detection A customer reported the issue to Maestro Engineering SME, who raised it internally with the team. The Maestro team investigated this failure, and observed an increasing number of failures for USI, and a few other tenants via logs, leading them to engage the Action Center team. ## Response The Maestro team received report of the issue from the customer via Email, and they did some initial investigation and identified a potential regression, following which, the Action Center SME was engaged, the issue reproduced on lower environments, a rollback of the feature applied and tested, and rolled out to all impacted regions. It was resolved with all instances being internally retried and resuming. ## Follow up 1. Add validation for this scenario across all cross service codebase surfaces to ensure human review 2. Add required monitoring and integration tests in place to detect this issue faster

We are investigating reports of intermittent slowness and errors affecting a subset of organizations in the East US region of Automation Cloud. Affected users may see pages in the Orchestrator UI fail to load (for example, the Jobs page returning "An error has occurred"), and robot operations such as queue transactions and session starts may intermittently time out. We will provide an update as soon as more information is available.

We have applied a capacity increase to the affected database infrastructure in the East US region and error rates and latency returned to normal levels. We will provide an update as soon as more information is available.

We have the issue in the East US region and error rates and latency returned to normal levels.

## Customer impact Between approximately 13:00 UTC and 18:15 UTC on October 7, 2026, customers in the US region experienced intermittent errors and slow responses in Orchestrator. Affected users may have seen Orchestrator pages fail to load, for example the Jobs page returning “An error has occurred,” and robot operations such as queue transactions and session starts may have intermittently timed out. Other UiPath services that depend on Orchestrator may also have seen slower responses or errors during this period. ## Root cause Several frequently-used Orchestrator operations each relied on a shared short-lived resource inside the database, including the routine status check that every running robot performs. As the volume of concurrent robot activity in this region grew, requests began queueing for access to that shared resource instead of completing their work. The effect was selective rather than a general slowdown: the operations that used this resource were delayed, while others continued to run normally. Because the database’s processor, memory and storage usage all remained within normal ranges, routine capacity monitoring did not indicate a problem. ## Detection Our automated monitoring detected the degradation within approximately 35 minutes of customer impact beginning, and our engineers identified the underlying contention during the event. Because this was a contention problem rather than a shortage of capacity, and all capacity indicators were normal, increasing database capacity was not expected to resolve it, and the team investigated alternatives before applying it. That assessment delayed the mitigation. ## Response Our engineering team increased the capacity of the affected database. Response times and error rates returned to normal immediately, and we continued monitoring to confirm the service was stable before closing the incident. * 13:00 : Error rates and response times begin to rise for customers in the US region. * 13:36 : Automated monitoring detects the degradation and notifies the on-call engineering team. * 13:36 – 17:29 : Engineers investigate. All standard database capacity indicators — processor, memory and storage — remain within normal ranges throughout, so the cause is not apparent from routine monitoring. * 17:29 : A formal incident is declared and the full response team is engaged. 17:38 A public notice is published on [UiPath Status](http://status.uipath.com/) \(Investigating\). * 17:31 – 17:43 : Additional database capacity is provisioned for the affected region. * 18:00 : Error rates, response times and request latency return to normal levels. * 18:11 : The status page is updated to Monitoring & Customer impact ends. * 19:06 : The incident is closed after continuous monitoring confirms the service is stable. ## Follow up To prevent this from happening again, we are: * Changing the affected operations so they no longer depend on the shared resource. This has been rolled out to all affected systems and has substantially reduced the condition that caused the incident. * Enabling detailed database monitoring on these systems, so this class of contention is visible while it is happening rather than afterwards. * Improving our alerting so that a genuine degradation of this kind is clearly distinguishable from routine, self-correcting variation, and is escalated faster.

We are investigating reports of an outage impacting [impacted functionality or user symptom] for Orchestrator in Europe. Impact: Users may expect delays for ingestion of robot logs and/or search/display of the logs. No logs will be lost. Next update: Our teams are working to understand the cause and scope and will share updates as available.

We have identified the cause for an outage impacting ingestion of robot logs for Orchestrator in Europe. Impact: Users may expect delays for ingestion of robot logs and/or search/display of the logs. No logs will be lost. Next update: Our teams are working to understand the cause and scope and will share updates as available.

We have mitigated the issue impacting ingestion of robot logs for Orchestrator in Europe. Impact: Users may expect delays for ingestion of robot logs and/or search/display of the logs. No logs will be lost. Next update: Our teams are working to understand the cause and scope and will share updates as available.

We have mitigated the issue impacting ingestion of robot logs for Orchestrator in Europe. Impact: Users may expect delays for ingestion of robot logs and/or search/display of the logs. No logs will be lost. Next update: Our teams are working to understand the cause and scope and will share updates as available.

## Customer impact On , between approximately 15:45 UTC and 18:45 UTC, customers hosted in the Europe, Australia and Japan regions were unable to see recent robot logs in Orchestrator. Logs written during the impact window did not appear in the Jobs and Logs views or through the Robot Logs API, and logs older than approximately 03:00 UTC that day were available only intermittently. The impact window differed per region: - Australia: approximately 15:45 UTC to 18:35 UTC - Europe: approximately 16:35 UTC to 18:00 UTC - Japan: approximately 16:45 UTC to 18:30 UTC Job execution, queues, triggers and all other Orchestrator functionality were not affected. No robot logs were lost. Logs produced during the impact window continued to be collected and became visible again once the issue was mitigated. ## Root cause We were performing a scheduled upgrade of the Elasticsearch service that stores Orchestrator robot logs. The upgrade uses a blue/green approach: a new cluster is created alongside the existing one, the data is restored into it from a backup, the pipeline that ingests new logs is started on it, and only then is traffic switched over. In the affected regions, the traffic switch was approved by the engineer running the upgrade before the data restore and the ingestion catch-up had completed, which is a deviation from our upgrade procedure. This was a human error. As a result, Orchestrator was reading robot logs from a cluster that did not yet contain recent data, while new logs continued to be collected but were not yet indexed on the cluster serving requests. The error was not caught because our deployment tooling relies on the operator to verify data completeness and does not enforce the order between the data restore and the traffic switch. ## Detection Our synthetic monitoring, which continuously runs test jobs and verifies that their logs are returned, detected missing logs in the affected regions and raised alerts. Our engineering team correlated the alerts with the in-progress upgrade, declared an incident and published a status page notification. ## Response Our engineering team reverted the traffic to the previous Elasticsearch clusters in all three regions, which immediately restored access to all robot logs, including those produced during the impact window. We confirmed recovery through synthetic monitoring in every affected region and continued monitoring before marking the incident resolved at approximately 18:45 UTC. The upgrade of the new clusters continues in the background. Traffic will be moved to them only after the data restore is complete and ingestion is confirmed to be up to date. ## Follow up To prevent this from happening again, we are: - Changing the deployment pipeline so that the traffic switch cannot run until the data restore and log ingestion on the new cluster are verified as complete. - Adding an automated rollback step to the pipeline, so traffic can be returned to the previous cluster within minutes if a problem is detected after a switch.

We are observing degraded performance for services in UAE

We are currently investigating this issue.

We have identified the issue as a network routing problem with a third-party service provider, affecting connectivity for our services hosted in the UAE. We are working with our upstream provider on resolution and will update progress here.

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

We are monitoring connectivity and will update this page once stability is confirmed.

We are continuing to monitor for any further issues.

The incident has been resolved.

## Customer impact Between 12:38 PM UTC and 2:51 PM UTC, a subset of customers in the UAE region experienced failures when accessing UiPath cloud services. The incident lasted approximately 2 hours and 13 minutes. Affected services included access to **cloud.uipath.com**, **account.uipath.com** Services hosted in UAE. Customers may have encountered timeouts, failed authentication, reset connections, or server errors. ## Root cause The root cause was a regional network routing failure at a third-party infrastructure provider. A subset of outbound network paths from the UAN region to specific external networks — including the content delivery network serving **cloud.uipath.com** and **account.uipath.com** — stopped delivering traffic. New outbound connection attempts from affected services did not receive responses, causing requests to time out. Our engineering team ruled out UiPath service configuration, application-level policy, and outbound connection capacity as causes. The infrastructure provider acknowledged a known issue affecting multiple customers on the same network path. ## Detection The issue was detected through automated monitoring. By approximately 12:40 pm UTC — roughly two minutes after the failure began — investigation confirmed that new connections from affected UAN region services to key UiPath endpoints were failing. ## Response By 1:20 pm UTC, our engineering team confirmed that the failure was limited to specific outbound network paths, while other destinations remained reachable. Validation ruled out UiPath-side routing changes, content delivery configuration changes, application-level policy, and outbound connection capacity issues. A high-severity support case was opened with the third-party infrastructure provider. At 1:50 pm UTC, the provider acknowledged a known issue affecting multiple customers. Our team continued monitoring recovery from the affected network paths and verifying service health as traffic returned. At 2:51 pm UTC, recovery checks confirmed that UiPath traffic through the affected content delivery paths had returned to normal levels. Automated health checks and service metrics confirmed recovery, and Services in UAN were operational. ## Follow up 1. We are pursuing the infrastructure provider's confirmed corrective action and root cause analysis for the regional routing failure. 2. We are reviewing outbound service dependencies in the affected region to strengthen resilience against similar third-party network disruptions.

Since about 15:05 UTC, some customers in the US region may see jobs that run on Cloud Robots take longer than usual to start, or stay in the Pending state. Jobs on your own robots are not affected, and neither are other regions. We've found the likely cause and are working to restore normal job processing. Jobs that are already queued are not lost and will be processed once the issue is resolved. We'll post another update within 60 minutes.

We've applied a fix for the issue that delayed jobs on Cloud Robots in the US region, and jobs are starting normally again. Jobs that were delayed are now being processed. We're monitoring to make sure the service stays stable and will post another update within 60 minutes.

After further work on the issue, jobs on Cloud Robots in the US region are now starting normally. Jobs that were delayed earlier are being processed. We're continuing to monitor the service and will post another update once the issue is resolved.

This issue has been resolved. Between 15:05 and 16:39 UTC, jobs on Cloud Robots in the US region were slow to start or stayed in the Pending state. Jobs have been starting normally since 16:39 UTC, and jobs that were delayed during this time have now been processed. We apologize for the disruption.

## Customer impact From 15:00 to 16:38 UTC on 2026-10-02, Cloud Robots jobs in the US region took longer than usual to start, up to 22 minutes at the peak around 16:20 UTC. Orchestrator stayed available, no job was lost, no other region was affected. A small number of customers received a temporary limit error on new submissions while their earlier jobs were waiting. ## Detection Automated alerts fired at 15:07 UTC, seven minutes after impact began. Checks in the US region failed from about 15:32 UTC and the incident response started. ## Root cause At 14:55 UTC one customer's workflow began submitting jobs at about 20 times its normal rate. The service that admits jobs keeps a per-customer concurrency count in the database and updates it under a database lock on every job start and end. At that rate the lock queue for the customer's record grew until updates timed out. The waiting updates occupied the shared pool of workers that starts jobs for all customers in the region, so every customer's jobs waited behind them. The mechanism meant to isolate one customer's load became the bottleneck. ## Response The team identified the overloaded admission path and the workload behind it. A first configuration change at 15:46 UTC targeted the wrong record and had no effect. The correct change at 16:10 UTC exempted that customer's job type from the database lock and took effect at about 16:20 UTC. Start times dropped from about 13 seconds to under one second and the backlog of about 5200 jobs drained in 18 minutes. Job starts were normal at 16:38 UTC. The customer's trigger was switched off with the customer at about 16:40 UTC. ## Follow up The database-locked rate limiting is replaced by in-memory high performance rate limiting mechanism, so one customer's load cannot block job starts for others. The change is complete, tested in pre-production at the same load, and being rolled out.

We are currently investigating an outage affecting the Insights portal in the UAE region. Users in this region may be unable to access the portal or may experience failed page loads. Our team is actively working to identify the cause and restore service. We will provide another update as soon as we have more information.

We have identified a mitigation path and are beginning a rollback in the UAE region. Users may continue to experience intermittent access issues with the Insights portal while this work is underway. We will provide another update once the rollback is complete.

The Insights portal in the UAE region is now loading successfully following our rollback. We are continuing to monitor the service to confirm stability and will provide a final update once we are confident the issue is fully resolved.

The Insights portal in the UAE region is now operating normally following the rollback. We have validated key portal functionality and confirmed the service remains healthy. This incident is now resolved.

## Customer Impact On **October 1, 2026**, the UiPath **Insights** service in the **UAE region** was unavailable. From approximately **23:40 UTC on October 1 to 00:39 UTC on October 2**, users could not load Insights dashboards: requests failed with an error after about 10 seconds. Requests to provision Insights for new tenants in the region also failed. The disruption lasted approximately **59 minutes**. Other UiPath services in the UAE region, and Insights in all other regions, were not affected. No customer data was lost. ## Root Cause The outage was caused by a **configuration change** that shipped in a scheduled Insights release. The change raised the **minimum TLS \(Transport Layer Security\) version** on the Insights application endpoints in the UAE region from TLS 1.2 to **TLS 1.3**, as part of a security hardening effort. The UiPath gateway that routes customer traffic to Insights connects to these endpoints over TLS 1.2. Once the endpoints stopped accepting TLS 1.2, the gateway could no longer open a secure connection to them. Customer requests timed out and returned errors, even though the Insights application itself stayed healthy. The change applied only to the UAE region, which is why no other region was affected. ## Detection The issue was detected by **UiPath's automated synthetic monitoring**, which continuously tests Insights availability from multiple locations. The first failed health check was recorded at 23:40 UTC. Automated alerts fired within minutes, and the on-call engineering team started investigating. ## Response The engineering team confirmed that the outage affected only Insights in the UAE region. The application was running normally, but no customer traffic was reaching it. The team traced the failure to the secure-connection step between the gateway and Insights, and linked it to the TLS setting applied by the release. At approximately **00:38 UTC**, the team restored the previous minimum TLS version \(TLS 1.2\) on the affected endpoints. Synthetic health checks began passing immediately, and by **00:41 UTC** all Insights checks in the UAE region were healthy. The team kept monitoring to confirm full stability. ## Follow-Up To prevent similar incidents in the future, we are taking the following steps: * **Remove the TLS change from the release** so that future deployments do not re-apply it, until the gateway supports TLS 1.3 end to end. * **Validate connection-security changes against the gateway** in a pre-production environment before they are applied to production.

Starting October 1 at approximately 1:30 PM UTC, some Agents, including both low-code and coded agents, began experiencing failures across all regions when using gemini-3.1-pro-preview and gpt-4o-2024-05-13. These models may also be unavailable for selection during agent design. We are actively investigating and working on a fix.

We have identified the issue and are deploying a fix. Agents using the affected models may continue to experience failures, and the models may remain unavailable for selection during agent design, while the deployment completes.

We have reverted the change that caused this issue and confirmed that the affected models are available again. Some agents may continue to experience intermittent failures while instances refresh. We are continuing to monitor agent design and execution for gemini-3.1-pro-preview and gpt-4o-2024-05-13.

## Customer impact On October 1, 2026, from 14:31 to 19:40 UTC, agents configured with some large language models, including Gemini 3.1 Pro Preview and GPT-4o (2024-05-13), failed to start in all regions, with an error saying the model is not available. The same models were missing from the model list while designing agents. Agents using other models were not affected. ## Root cause A feature flag was flipped, causing Agents service to begin sending an operation code to model discovery requests. This caused the list of models served to be that specific operation’s as opposed to the base agents model list. The per operation model list was initially seeded from the Bring Your Own Model (BYOM) configuration of overridable models, which crucially for agents did not have parity with the full list of supported models in Agents service. Internal audit showed this was an error and not an intentional gap. Over time this gap was never addressed and after the flag switch, agents already configured with any of the affected models would fail because of their absence from the returned list. ## Detection A customer reported the issue, and it was escalated to our engineers at 16:44 UTC. Our monitoring did not alert, because this error usually points to organization or agent level configuration issues. ## Response Engineers traced the failures to the configuration change and reverted it at 19:01 UTC. The revert took effect over the following minutes, and the last failure occurred at 19:40 UTC. ## Follow up 1. The model lists will be aligned before this change is made again. 2. We're changing how this error is classified so a platform-wide spike alerts our engineers.

Starting October 1 at approximately 12:00 PM UTC, community users in Europe may experience failures in LowCode Agents that use solution-local Action Apps. We have confirmed the impact is limited to community users in Europe. We are actively investigating the issue, determining the extent of the failures, and working on a fix.

We have identified the issue causing failures in low-code agents that use solution-local action apps for community users in Europe. We are rolling back the previous changes and continuing to monitor the recovery. We will provide another update once rollback is complete or if we have additional information to share.

We have confirmed that the rollback has completed and the issue affecting low-code agents that use solution-local action apps for community users in Europe has been resolved. Services have recovered, and we are closing this incident.

## Customer impact On October 1, 2026, from 10:50 to 19:50 UTC, some Studio Web users in Europe couldn't debug agents that call Orchestrator processes (RPA, agents, etc.) or Action Apps from the same solution. The call failed with a "not found" error. Published agents and production jobs were not affected. ## Root cause A Studio Web update changed how solution resources are located during debugging. It was missing a setting that keeps the previous behavior, so debug runs looked for the solution's resources in the user's personal workspace instead of the debug folder. ## Detection Automated end-to-end tests alerted our engineers at 16:43 UTC. The end-to-end testing suite runs once every 2 hours and alerting only happens after 3 consecutive test failures. The issue was also reported from a customer environment. ## Response After identifying the root cause, a rollback was started at 18:00 UTC and was fully in effect at 19:50 UTC. This duration included a deployment failure that had to be retried, which took 50 minutes. A corrected version that includes the setting was deployed on October 2 at 13:00 UTC. ## Follow up 1. The setting is now part of the main code line, so future releases include it. 2. We're improving the alerts and the end-to-end testing suite to catch regressions earlier.

Between 14:23 and 16:04 UTC on 1 October 2026, some requests to delete items in UiPath Automation Cloud services in the Australia region failed with "404 Not Found" errors. Services affected included Orchestrator, Document Understanding, AI Center and Data Service. Other operations, such as viewing, creating and updating items, worked normally. The cause was a configuration change to our request routing. We rolled it back and the service is fully restored.

## Customer impact Between October 1, 2026 at 2:23 pm UTC and 4:04 pm UTC, a subset of customers experienced **404 Not Found** errors for some UiPath Automation Cloud requests in the Australia region. The incident lasted 1 hour and 41 minutes. Affected requests included delete operations and some Robot connection checks. Services affected included Orchestrator, Document Understanding, AI Center, and Data Service. Robot jobs that called Orchestrator may have failed, and customers may need to rerun any Robot jobs that failed during this window. All other operations were not affected. ## Root cause A routing configuration change was applied to the Australia region with an incomplete set of supported operations due to a timeout in the release pipeline. Delete operations were missing from the configuration, so those requests were rejected at the routing layer with **404 Not Found** before reaching the underlying services. ## Detection Automated end-to-end monitoring detected the issue by alerting on failures for Document Understanding service checks. Our engineering team then used internal monitoring data to confirm the broader pattern of failures across affected services. ## Response During investigation, monitoring data showed that requests routed through the Australia region were returning **404 Not Found** errors, while requests routed through other regions were unaffected. Analysis identified that the start time of **404 Not Found** response increase was correlated with the time when the routing configuration came in effect. The team reverted the routing configuration to the prior working version. After the revert, monitoring showed error counts dropping within approximately three minutes, and the service was fully restored by October 1, 2026 at 4:04 pm UTC. ## Follow up 1. Improve routing layer alerts on 4xx baseline changes 2. Detect partially applied routing configurations before having them take effect

Our team is actively working on a fix for the degraded performance affecting Orchestrator in the US region. We will share updates as progress is made.

A fix is currently being deployed for the degraded performance affecting Orchestrator and Action Center in the US region. Further updates will follow.

A fix has been implemented for the degraded performance affecting Orchestrator and Action Center in the US region. Our team is actively monitoring the results to confirm the issue is fully resolved.

A fix has been implemented for the degraded performance affecting Orchestrator and Action Center in the US region. We are continuing to monitor system performance and stability to confirm the issue is fully resolved. Further updates will be provided as more information becomes available.

The degraded performance affecting Orchestrator and Action Center in the US region has been resolved. System performance has remained stable following the implemented fix, and we will continue standard monitoring.

## Customer impact Between approximately 11:00 UTC and 13:40 UTC on October 1, 2026, customers in the US region observed slower Orchestrator response times and intermittent timeouts. Robots took longer to start jobs, process queue items and read assets, and some of these requests failed. Other UiPath services that rely on Orchestrator were also affected while Orchestrator was degraded, and may have seen slower responses or errors. ## Root cause An Orchestrator fix deployment included a change to how computing capacity is reserved and scaled for our services. The change was meant to use our infrastructure more efficiently, but it lowered the processing capacity available to Orchestrator. During busy periods our automatic scaling did not add capacity as expected, so the service could not keep up with demand. ## Detection Our internal monitoring detected the slowdown after the update. Our first plan was to release a corrected update through our standard release process, which takes several hours. When customer reports began coming in, we opened an incident and moved to a faster fix. ## Response Our engineering team applied the previous capacity settings directly to the affected services, without waiting for the corrected update. Response times returned to normal at approximately 13:40 UTC, and we continued monitoring to confirm the service was stable. ## Follow up To prevent this from happening again, we are: - Permanently restoring the previous capacity settings, and reviewing any future capacity changes against production-level load before rollout. - Improving how we assess customer impact during degradations, so they are escalated to an incident earlier. - Making it faster to roll back capacity and configuration changes when they affect customers.

We are investigating degraded performance impacting UiPath Service from LLM Gateway in Multiple Regions. Our teams are working to identify the cause and we will share more details as the investigation progresses.

A fix has been implemented, and our team is actively monitoring the results to confirm the issue is fully resolved.

We continue to monitor the results of the implemented fix to ensure the issue is fully resolved.

The issue has been resolved, and services are operating normally. We apologize for any inconvenience this may have caused.

## Customer impact Between October 1, 2026 at 03:00 UTC and October 1, 2026 at 04:10 UTC, a subset of customers experienced intermittent failures when using AI-powered features, including Context Grounding, Agent Builder and Agents, Autopilot for Developers, generative AI activities, and Communications Mining. Impact affected requests served by or routed through our Europe AI services infrastructure. Affected regions include UAE, Korea, Switzerland, UK, India, Singapore, Australia and Europe. Customers saw failed requests, including service-unavailable errors. Failures were concentrated during two periods 03:00 UTC to 03:45 UTC and 04:00 UTC to 04:08 UTC for a total incident window of approximately 1 hour and 10 minutes. ## Root cause A single image-processing workload sent a large batch of requests with very large image payloads to our Europe AI services infrastructure. Those oversized request bodies caused service instances to exhaust available memory, become unresponsive, and restart. As healthy capacity dropped, our systems returned service-unavailable errors for customer traffic. When traffic was automatically rerouted to a second Europe location, the same failure pattern occurred because both locations received the same oversized workload. ## Detection Our monitoring systems generated multiple concurrent alerts shortly after failures began at approximately 03:00 UTC. During the initial investigation, our engineering team confirmed that Europe AI service failures were causing customer-facing errors across multiple products and regions. ## Response During the investigation, our engineering team identified the source workload and defined mitigation options: stopping the workload at its source, or blocking its traffic before it reached the affected services. As a short-term stabilisation measure, service memory limits were increased. Telemetry confirmed two failure periods 03:00 UTC to 03:45 UTC and 04:00 UTC to 04:08 UTC. By 04:10 UTC, service-unavailable errors had dropped to near zero and no additional service restarts were observed. A traffic block was then applied to prevent the source workload from reaching the affected services. The source workload was confirmed to have stopped at approximately 04:46 UTC, and no further traffic from it was observed afterward. ## Follow up 1. We are adding enforcement at the service level to reject or safely handle oversized image payloads before they can exhaust service memory. 2. We are adding a per-organization concurrency limit for Context Grounding image processing to prevent a single workload from affecting service availability for other customers.

We are investigating issues with Maestro execution trails in the UK region. Some customers may observe the execution trail missed. No impact to instance's executions.

We have identified the cause of the issue affecting Maestro execution trails in the UK region and are working on a fix.

A fix has been applied for the issue affecting Maestro execution trails in the UK region, and new execution trails are being recorded normally. We are restoring the missing execution trails for affected executions and are monitoring the results. Instance executions were not impacted.

The fix for Maestro execution trails in the UK region is holding, and new trails continue to be recorded normally. We are still working on restoring the missing trails for affected executions and will provide another update when that's complete.

We are continuing to restore the missing Maestro execution trails in the UK region. New execution trails are unaffected and continue to be recorded normally. We will share another update as progress is made.

Restoration of the missing Maestro execution trails in the UK region is progressing, and a portion of the affected trails have been recovered. Work is ongoing to restore the remainder.

Restoration of the missing Maestro execution trails in the UK region is nearly complete. We are finishing the remaining work and expect to resolve this incident shortly.

We are in the final stage of restoring the missing Maestro execution trails in the UK region, with only a small number of trails remaining. We expect restoration to be complete soon and will post a final update once this incident is resolved.

This incident has been resolved. All missing Maestro execution trails in the UK region have been restored, and new execution trails are being recorded normally. Instance executions were not impacted at any point. We apologize for the inconvenience this may have caused.