UiPath Outage History

Started Oct 23, 2026, 08:42 PM UTC· resolved Oct 23, 2026, 09:19 PM UTC

1. resolved Oct 23, 2026, 09:35 PM UTC

   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.

Read the full incident report →

Started Oct 22, 2026, 12:59 PM UTC· resolved Oct 22, 2026, 09:02 PM UTC

1. investigating Oct 22, 2026, 12:59 PM UTC

   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

2. monitoring Oct 22, 2026, 02:19 PM UTC

   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

3. investigating Oct 22, 2026, 02:33 PM UTC

   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.

4. investigating Oct 22, 2026, 03:42 PM UTC

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

5. monitoring Oct 22, 2026, 05:56 PM UTC

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

6. resolved Oct 22, 2026, 09:02 PM UTC

   Issue is resolved from Google.

Read the full incident report →

Started Oct 15, 2026, 12:27 PM UTC· resolved Oct 15, 2026, 01:22 PM UTC

1. investigating Oct 15, 2026, 12:27 PM UTC

   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.

2. monitoring Oct 15, 2026, 01:04 PM UTC

   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.

3. resolved Oct 15, 2026, 01:22 PM UTC

   This incident has been resolved. Between 11:17 and 12:44 UTC, a configuration change impacted UiPath Agents and Solutions Management across multiple regions, causing job-start delays and deployment timeouts. The change was rolled back, and monitoring confirms that services are operating normally. Thank you for your patience.

4. postmortem Oct 21, 2026, 06:47 AM UTC

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

Read the full incident report →

Started Oct 15, 2026, 11:20 AM UTC· resolved Oct 15, 2026, 11:45 AM UTC

1. resolved Oct 15, 2026, 12:03 PM UTC

   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.

2. postmortem Oct 22, 2026, 10:13 AM UTC

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

Read the full incident report →

Started Oct 14, 2026, 07:26 AM UTC· resolved Oct 14, 2026, 07:43 AM UTC

1. monitoring Oct 14, 2026, 07:26 AM UTC

   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.

2. resolved Oct 14, 2026, 07:43 AM UTC

   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.

3. postmortem Oct 23, 2026, 12:08 PM UTC

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

Read the full incident report →

Started Oct 13, 2026, 02:03 PM UTC· resolved Oct 13, 2026, 03:19 PM UTC

1. investigating Oct 13, 2026, 02:03 PM UTC

   We are investigating a regional outage impacting UiPath Cloud services in in multiple regions Impact: Users are unable to access services hosted in the affected regions. Next update: Additional information will be shared as it becomes available.

2. investigating Oct 13, 2026, 02:37 PM UTC

   We are continuing to investigate this issue.

3. investigating Oct 13, 2026, 02:42 PM UTC

   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.

4. investigating Oct 13, 2026, 03:10 PM UTC

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

5. resolved Oct 13, 2026, 03:19 PM UTC

   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.

Read the full incident report →

Started Oct 13, 2026, 10:32 AM UTC· resolved Oct 13, 2026, 10:57 AM UTC

1. investigating Oct 13, 2026, 10:32 AM UTC

   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.

2. resolved Oct 13, 2026, 10:57 AM UTC

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

3. postmortem Oct 22, 2026, 01:25 PM UTC

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

Read the full incident report →

Started Oct 07, 2026, 09:34 PM UTC· resolved Oct 08, 2026, 04:29 AM UTC

1. investigating Oct 07, 2026, 09:34 PM UTC

   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.

2. identified Oct 07, 2026, 10:16 PM UTC

   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.

3. identified Oct 07, 2026, 11:26 PM UTC

   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.

4. identified Oct 08, 2026, 12:29 AM UTC

   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.

5. identified Oct 08, 2026, 01:30 AM UTC

   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.

6. monitoring Oct 08, 2026, 02:29 AM UTC

   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.

7. monitoring Oct 08, 2026, 03:28 AM UTC

   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.

8. resolved Oct 08, 2026, 04:29 AM UTC

   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.

Read the full incident report →

Started Oct 07, 2026, 05:37 PM UTC· resolved Oct 07, 2026, 07:06 PM UTC

1. investigating Oct 07, 2026, 05:37 PM UTC

   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.

2. monitoring Oct 07, 2026, 06:13 PM UTC

   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.

3. resolved Oct 07, 2026, 07:06 PM UTC

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

4. postmortem Oct 14, 2026, 11:42 AM UTC

   ## 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. **Time (UTC)** **Event** 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 [http://status.uipath.com](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.

Read the full incident report →

Started Oct 06, 2026, 05:50 PM UTC· resolved Oct 06, 2026, 06:44 PM UTC

1. investigating Oct 06, 2026, 05:50 PM UTC

   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.

2. identified Oct 06, 2026, 06:02 PM UTC

   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.

3. identified Oct 06, 2026, 06:28 PM UTC

   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.

4. monitoring Oct 06, 2026, 06:43 PM UTC

   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.

5. resolved Oct 06, 2026, 06:44 PM UTC

   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.

6. postmortem Oct 07, 2026, 11:08 AM UTC

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

Read the full incident report →

Started Oct 06, 2026, 12:38 PM UTC· resolved Oct 06, 2026, 05:09 PM UTC

1. identified Oct 06, 2026, 12:38 PM UTC

   We are observing degraded performance for services in UAE

2. investigating Oct 06, 2026, 12:43 PM UTC

   We are currently investigating this issue.

3. identified Oct 06, 2026, 02:01 PM UTC

   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.

4. identified Oct 06, 2026, 02:22 PM UTC

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

5. monitoring Oct 06, 2026, 02:51 PM UTC

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

6. monitoring Oct 06, 2026, 03:07 PM UTC

   We are continuing to monitor for any further issues.

7. monitoring Oct 06, 2026, 03:09 PM UTC

   We are continuing to monitor for any further issues.

8. resolved Oct 06, 2026, 05:09 PM UTC

   The incident has been resolved.

9. postmortem Oct 21, 2026, 05:36 AM UTC

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

Read the full incident report →

Started Oct 02, 2026, 04:23 PM UTC· resolved Oct 02, 2026, 05:03 PM UTC

1. investigating Oct 02, 2026, 04:23 PM UTC

   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.

2. monitoring Oct 02, 2026, 04:34 PM UTC

   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.

3. monitoring Oct 02, 2026, 04:51 PM UTC

   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.

4. resolved Oct 02, 2026, 05:03 PM UTC

   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.

5. postmortem Oct 14, 2026, 02:20 PM UTC

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

Read the full incident report →

Started Oct 02, 2026, 12:13 AM UTC· resolved Oct 02, 2026, 12:51 AM UTC

1. investigating Oct 02, 2026, 12:13 AM UTC

   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.

2. identified Oct 02, 2026, 12:36 AM UTC

   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.

3. monitoring Oct 02, 2026, 12:41 AM UTC

   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.

4. resolved Oct 02, 2026, 12:51 AM UTC

   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.

5. postmortem Oct 05, 2026, 10:58 PM UTC

   ## 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. ## Incident Postmortem - Postmortem landing page

Read the full incident report →

Started Oct 01, 2026, 06:57 PM UTC· resolved Oct 01, 2026, 07:46 PM UTC

1. investigating Oct 01, 2026, 06:57 PM UTC

   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.

2. identified Oct 01, 2026, 07:05 PM UTC

   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.

3. resolved Oct 01, 2026, 07:46 PM UTC

   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.

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

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

Read the full incident report →

Started Oct 01, 2026, 06:17 PM UTC· resolved Oct 01, 2026, 08:08 PM UTC

1. investigating Oct 01, 2026, 06:17 PM UTC

   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.

2. identified Oct 01, 2026, 06:25 PM UTC

   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.

3. resolved Oct 01, 2026, 08:08 PM UTC

   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.

4. postmortem Oct 07, 2026, 02:28 PM UTC

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

Read the full incident report →

Started Oct 01, 2026, 02:00 PM UTC· resolved Oct 01, 2026, 04:04 PM UTC

1. resolved Oct 01, 2026, 04:32 PM UTC

   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.

2. postmortem Oct 07, 2026, 10:15 AM UTC

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

Read the full incident report →

Started Oct 01, 2026, 01:21 PM UTC· resolved Oct 01, 2026, 07:03 PM UTC

1. investigating Oct 01, 2026, 01:21 PM UTC

   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.

2. identified Oct 01, 2026, 02:06 PM UTC

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

3. monitoring Oct 01, 2026, 02:24 PM UTC

   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.

4. monitoring Oct 01, 2026, 03:34 PM UTC

   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.

5. monitoring Oct 01, 2026, 04:46 PM UTC

   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.

6. monitoring Oct 01, 2026, 05:58 PM UTC

   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.

7. resolved Oct 01, 2026, 07:03 PM UTC

   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.

8. postmortem Oct 05, 2026, 06:40 AM UTC

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

Read the full incident report →

Started Oct 01, 2026, 04:12 AM UTC· resolved Oct 01, 2026, 07:48 AM UTC

1. investigating Oct 01, 2026, 04:12 AM UTC

   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.

2. monitoring Oct 01, 2026, 05:42 AM UTC

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

3. monitoring Oct 01, 2026, 06:28 AM UTC

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

4. resolved Oct 01, 2026, 07:48 AM UTC

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

5. postmortem Oct 06, 2026, 02:35 PM UTC

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

Read the full incident report →

Started Sep 26, 2026, 04:46 PM UTC· resolved Sep 27, 2026, 12:36 AM UTC

1. investigating Sep 26, 2026, 04:46 PM UTC

   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.

2. identified Sep 26, 2026, 05:15 PM UTC

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

3. monitoring Sep 26, 2026, 05:46 PM UTC

   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.

4. monitoring Sep 26, 2026, 06:58 PM UTC

   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.

5. monitoring Sep 26, 2026, 08:22 PM UTC

   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.

6. monitoring Sep 26, 2026, 09:39 PM UTC

   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.

7. monitoring Sep 26, 2026, 10:55 PM UTC

   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.

8. monitoring Sep 27, 2026, 12:07 AM UTC

   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.

9. resolved Sep 27, 2026, 12:36 AM UTC

   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.

Read the full incident report →

Started Sep 24, 2026, 09:45 PM UTC· resolved Sep 24, 2026, 10:50 PM UTC

1. investigating Sep 24, 2026, 09:45 PM UTC

   We're investigating issues with robot live streaming in the US region. We'll share an update as soon as we have more information.

2. monitoring Sep 24, 2026, 10:24 PM UTC

   We've identified the cause of the robot live streaming issues in the US region and applied a fix. We're actively monitoring to confirm the issue is fully resolved.

3. resolved Sep 24, 2026, 10:50 PM UTC

   The issue affecting robot live streaming in the US region has been resolved. Live streaming is working as expected. We apologize for any inconvenience.

4. postmortem Oct 07, 2026, 10:20 AM UTC

   ## Customer impact Between 14:14 UTC and approximately 21:50 UTC on , customers in the US region were unable to start or view robot live streams. Robot job execution was not affected. ## Root cause On , we performed a planned rotation of the keys used to authorize live-stream connections. The US live streaming service loads these keys only at startup and had not been restarted after the new key was provisioned. As a result, the US live streaming service could not validate newly issued access tokens and rejected all connection attempts. ## Detection The issue was reported by customers as robot live streaming failing to connect in the US region. Our internal monitoring also detected the increase in errors. ## Response Our engineering team correlated the authorization failures with the key rotation and performed a rolling restart of the US live streaming service so it loaded the current keys. Errors stopped at approximately 21:50 UTC. After confirming live streams were connecting successfully, we resolved the incident at 22:50 UTC. ## Follow up To prevent recurrence of this issue, we are implementing several improvements: - Enable the live streaming service to reload keys without requiring a restart. - Recalibrate alerting and monitoring mechanism.

Read the full incident report →

Started Sep 22, 2026, 06:04 AM UTC· resolved Sep 22, 2026, 07:31 AM UTC

1. identified Sep 22, 2026, 06:04 AM UTC

   We have identified an issue affecting Advanced Forms in Action Center for users in the Community, Canada, and Australia regions. A hotfix deployment is currently in progress. Impact: Users may be unable to scroll or edit Form Tasks as expected when using Advanced Forms. Workaround: Use the Tab key to navigate through the form and make edits instead of clicking or scrolling. Next update: Our focus is on completing and validating the hotfix deployment and restoring full functionality and share and update quickly as possible

2. monitoring Sep 22, 2026, 07:04 AM UTC

   The fix has been successfully applied, and the service is currently under monitoring. Users should now be able to scroll and edit Form Tasks in Action Center when using Advanced Forms. We will continue monitoring the service to confirm that the issue remains resolved.

3. resolved Sep 22, 2026, 07:31 AM UTC

   The fix has been applied and validated, and the service is operating normally

4. postmortem Sep 28, 2026, 12:04 PM UTC

   ## Customer Impact Customers using Action Center in the Australia, Canada and subset of users from Europe regions were unable to click on or edit fields in Advanced Form Tasks. Because the form could not be edited with the mouse, affected users could not fill in, save or complete these tasks through the normal workflow. Fields could still be reached with the keyboard Tab key, so users were not fully blocked. All other task types, and Form Tasks using the standard form layouts, were not affected. Impact began after an Action Center update was deployed to these regions on the evening of September 21, 2026, and ended on September 22, 2026 at approximately 07:30 UTC, when the fix was deployed to all affected regions. Total duration was approximately 12 hours. ## Root Cause The Action Center update included a new feature that lets customers save a task directly from the task view when Action Center tasks are embedded inside Case apps. To make the save option visible in that embedded view, a styling (CSS) change was made that places the save control on a higher display layer than the task details. The feature logic itself was only enabled for embedded tasks, but the styling change could not be limited in the same way and was applied to every task view. Advanced Form Tasks render their form inside a separate, isolated container so that they can support additional custom controls. For these forms, the new display layer sat on top of the form, creating an invisible overlay that captured mouse clicks and prevented users from interacting with the form fields. The change was tested manually and through automated end-to-end tests across all task types before release. However, the Form Tasks used in testing all used the default, standard form layout. Advanced Form Tasks, which developers must explicitly enable in UiPath Studio, were not part of the test coverage, so the issue was not detected before the update reached production. ## Detection The issue was detected through customer reports. The first report arrived as a high-severity support ticket on September 22, 2026 at 00:30 UTC, which paged the on-call engineer, followed by a second report through a support help request at 01:30 UTC. The update was deployed outside business hours, and the post-deployment automated validation passed in each region because it did not cover Advanced Form Tasks. As tasks still loaded and no errors were generated, there was no alert or monitoring signal for this issue, and it only became visible once users started working on these tasks during business hours. ## Response The on-call engineer engaged immediately after being paged and brought in the engineers who owned the change. While the fix was being prepared, affected customers were given a workaround to use the keyboard Tab key to move between and edit form fields, which was confirmed as working. Mitigation began at 00:30 UTC and the issue was fully resolved at 07:30 UTC on September 22, 2026. Timeline (September 22, 2026, UTC): - 00:30 – First customer report received; on-call engineer paged and engaged immediately. - 01:30 – Second customer report received through support. - 02:20 – Root cause identified and reproduced in a test environment. - 03:30 – Fix validated in a test environment. - 05:30 – Fix validated in the pre-production environment. - 07:30 – Fix deployed and validated in all affected production regions (Community, Australia and Canada). Issue resolved. ## Follow-Up **Short-term** - The styling change has been corrected so that it applies only to tasks embedded in Case apps and no longer affects the standard task view or Advanced Form Tasks. - We are adding Advanced Form Tasks (form layout version 3) to our manual and automated end-to-end test suites for Action Center. **Long-term** - We will include Advanced Form Tasks in the automated validation that runs after every Action Center deployment, in every region, so that this type of issue is caught before it can reach customers. - We will review our test coverage to make sure every supported form layout version is exercised when changes are made to the task view.

Read the full incident report →

Started Sep 18, 2026, 08:25 AM UTC· resolved Sep 18, 2026, 06:03 PM UTC

1. resolved Sep 18, 2026, 06:03 PM UTC

   During the General Availability (GA) rollout of Maestro Flow, an issue was identified in the South Korea region where one of the scale units had not been deployed, causing the flow to fail.

2. postmortem Oct 22, 2026, 05:31 AM UTC

   ## Customer impact Customers in the South Korea region could not open the Maestro Flow design experience. Creating a Maestro Flow or Maestro Automate project succeeded, but the editor then failed to load with the message "The editor failed to load. Please retry or try again later." The issue affected the design experience only; execution of existing flows was not affected, and no other region was affected. The issue was present from the start of the Maestro Flow public preview on until . It affected 12 trial organisations in the South Korea region; no enterprise customers were affected. ## Root cause Maestro Flow was never deployed to the South Korea infrastructure. When the region was prepared for services in May 2026, Maestro Flow was still in private preview and was intentionally excluded from that region as "not ready yet". That exclusion had no owner or review date. When Maestro Flow later opened to public preview and then to general availability, the product entry points were enabled in South Korea without checking that the service behind them was deployed there. No health check covered Maestro Flow in that region, so the failure was not visible internally until a customer reported it. ## Detection A customer report was received at 08:25 UTC on . No internal alert fired. Investigation confirmed that the Maestro Flow service was absent from the South Korea infrastructure rather than failing after startup. ## Response By 09:49 UTC the Maestro Flow and Maestro Automate entry points were hidden in the South Korea region, so customers no longer encountered the failing editor, and creating a tenant in another region was offered as a workaround. The deployment owners were engaged, and the missing deployment configuration was identified at 17:35 UTC. Maestro Flow was deployed to the South Korea infrastructure at 17:50 UTC and verified working. The configuration was corrected permanently, and the entry points were re-enabled in South Korea at 18:22 UTC. The customer confirmed the fix at 22:00 UTC. The public status page was updated at 18:03 UTC. ## Follow up 1. Automated health checks for Maestro Flow now run in the South Korea, UAE and Switzerland regions, in addition to the regions already covered. Remaining gaps in those checks are being closed. 2. Any decision to exclude a service from a region will require a recorded reason and review date, and stale exclusions will be reported automatically. 3. Enabling a product in a region will require confirming that the service is deployed and monitored in that region first. 4. An alert on editor load failures, per region, is being added as an independent safeguard.

Read the full incident report →

Started Sep 16, 2026, 03:24 PM UTC· resolved Sep 16, 2026, 07:41 PM UTC

1. investigating Sep 16, 2026, 03:24 PM UTC

   We are investigating reports of an outage impacting Action Center task creation for Maestro in the United States, Australia, Canada, Singapore, India, and Community regions. Impact: Users may be unable to create Action Center tasks. Next update: Our teams are working to understand the cause and scope and will share updates as available.

2. identified Sep 16, 2026, 03:32 PM UTC

   We have identified the cause of the outage impacting Action Center task creation for Maestro in multiple regions and are working on a fix. Impact: Users may continue to be unable to create Action Center tasks. Next update: We are preparing a mitigation which will restore the functionality, and will provide an update shortly.

3. identified Sep 16, 2026, 04:30 PM UTC

   We have established a mitigation, which is being applied to all affected regions. We will provide an update once the mitigation is rolled out.

4. monitoring Sep 16, 2026, 05:44 PM UTC

   A fix has been deployed for the issue impacting Action Center task creation for Maestro, and we are monitoring closely. Impact: Users may still experience task creation failures while the mitigation takes effect. Next update: We are continuing to monitor system behavior.

5. monitoring Sep 16, 2026, 06:56 PM UTC

   A fix has been deployed for the issue impacting Action Center task creation for Maestro, and we are monitoring closely. Impact: Users may still experience task creation failures while the mitigation takes effect. Next update: We are continuing to monitor system behavior.

6. resolved Sep 16, 2026, 07:41 PM UTC

   The issue has been resolved

7. postmortem Oct 01, 2026, 02:44 AM UTC

   ## Customer impact Between September 14, 2026 at 12:45 UTC and September 16, 2026 at 17:30 UTC, a subset of customers experienced failures when Maestro processes attempted to create human-in-the-loop tasks in Action Center. The first customer report reached UiPath on September 16 at 12:24 UTC and an incident was declared at 14:37 UTC, so a number of process runs failed before the issue was formally identified. Affected process runs faulted at the human-in-the-loop step with the error "Invalid input for the HITL task" and no Action Center task was created. No tasks were lost or duplicated, and no data was corrupted. Process runs that had already passed the human-in-the-loop step were not affected. The impact was limited to a small subset of organizations, primarily in the United States, Canada, Australia, and India regions, whose Maestro processes met a specific condition: the process used an Action App and the app's folder path had no value at run time. Canada and Singapore received the change but had no affected process runs. _**Action for affected customers: process runs that failed during this window did not recover automatically. If you have process runs that faulted at a human-in-the-loop step between September 14 and September 16 and have not yet been retried, please retry them from Maestro or contact UiPath Support with the process instance IDs.**_ ## Root cause A recent Maestro service update added input validation to the human-in-the-loop task creation step. The change was intended to return a clear, non-retried error when a task is genuinely misconfigured, specifically when the Action App name is missing. The same validation also treated an empty app folder path as a misconfiguration. An empty folder path is, however, a valid and supported configuration: Maestro resolves it to the folder of the running process. The new validation rejected the request before that default behavior could apply, so task creation failed for every process run in which the folder path was empty. The change passed pre-production testing because the test processes all carried an explicit app folder path, so the empty-folder-path scenario was not exercised before release. ## Detection The issue was identified on September 16, 2026 at 12:24 UTC through customer-reported process failures. The new validation classified the failure as a user configuration error rather than a service error. Configuration errors in that category are intentionally excluded from our availability monitoring, so no automated alert fired and detection relied on customer reports. Our team opened an investigation immediately and confirmed within minutes that the failures originated in Maestro before any call to Action Center. ## Response At 3:24 pm UTC on September 16, 2026, we posted a public status update acknowledging Action Center task creation failures in Maestro. By 3:28 pm UTC the cause had been identified as the recent validation change, and by 4:30 pm UTC we communicated that a fix was being applied to the affected regions. The fix removed the validation that blocked task creation when the folder path was empty, restoring the previous default behavior. After verifying the fix in our testing environment against the exact empty-folder-path scenario, deployment to production began at 4:33 pm UTC and completed across all affected regions by 5:29 pm UTC. The incident was marked as mitigated at 5:44 pm UTC. We continued monitoring recovery and customer-reported behavior. A follow-up status update was posted at 6:56 pm UTC, and the incident was resolved at 7:41 pm UTC after confirming with affected customers that new and retried processes were completing successfully. The incident was declared resolved at 19:41 UTC after confirming with affected customers that new and retried processes were completing successfully. From first failed run to last, the defect was live in production for 52 hours and 45 minutes; the declared incident covered the final 5 hours and 3 minutes. ## Follow up 1. Re-apply the intended improvement in a corrected form: return a clear error only when the Action App name is missing, and leave the empty-folder-path default behavior unchanged. The corrected change is under review and will be released with standard validation. 2. Add an automated end-to-end test that runs with exact customer scenario to catch these sort of issues early. 3. Add alerting for spikes in this class of task-creation errors that operates independently of availability monitoring 4. Add alerts for 4xx anomalies to catch other unexpected issues. 5. Provide tooling to identify and retry failed process runs in bulk after a fix is deployed, so recovery does not depend on manual retries by customers.

Read the full incident report →

Started Sep 16, 2026, 09:14 AM UTC· resolved Sep 16, 2026, 05:46 PM UTC

1. identified Sep 16, 2026, 09:14 AM UTC

   We are experiencing degraded performance in the Customer Portal due to an ongoing third-party service outage affecting multiple instances globally. Affected Customer Portal functionality (major impact): Creating and updating support cases Viewing existing support case details and replies Loading account and company data Checking case status during self-registration Downloading files Our team is actively monitoring the situation and will provide further updates as they become available.

2. identified Sep 16, 2026, 10:21 AM UTC

   Our team is actively monitoring the situation and will provide further updates as they become available.

3. identified Sep 16, 2026, 11:29 AM UTC

   Our team is actively monitoring the situation and will provide further updates as they become available.

4. identified Sep 16, 2026, 12:29 PM UTC

   Service provider is implementing fix, Our team is actively monitoring the situation and will provide further updates as they become available.

5. identified Sep 16, 2026, 01:29 PM UTC

   Service provider is making progress in fix implementation, Our team is actively monitoring the situation and will provide further updates as they become available.

6. identified Sep 16, 2026, 02:31 PM UTC

   Service provider is making progress in fix implementation, Our team is actively monitoring the situation and will provide further updates as they become available.

7. identified Sep 16, 2026, 03:34 PM UTC

   Service provider is making progress in fix implementation, Our team is actively monitoring the situation and will provide further updates as they become available.

8. identified Sep 16, 2026, 04:51 PM UTC

   Service provider is making progress in fix implementation, Our team is actively monitoring the situation and will provide further updates as they become available.

9. resolved Sep 16, 2026, 05:46 PM UTC

   The upstream service provider has resolved their outage, and we are seeing functionality return to normal for the previously affected Customer Portal functionalities.

10. postmortem Oct 01, 2026, 05:24 AM UTC

    ## Customer Impact **Regions Affected: Global (all regions)** **Services Affected:** Customer Portal - Support Cases, Account & Company Data, Self-Registration, File Downloads **Timeframe:** - **Impact Start:** September 16, 2026, 8:15 am UTC - **Impact End:** September 16, 2026, 12:00 pm UTC - **Total Duration:** ~3 hours 45 minutes **Impact Type:** Partial / intermittent - a subset of requests failed across all regions while the portal remained largely available throughout. **Customer Experience - Failed Operations:** - **Support Cases:** Creating and updating support cases, viewing existing case details and replies, and handling attachments - **Account & Company Data:** Loading account and company information - **Self-Registration:** Checking case status during self-registration - **File Downloads:** Downloading files **No customer data was lost.** Affected operations failed cleanly (requests were rejected or timed out) and could be completed by retrying once the service recovered; no data was corrupted or dropped. --- ## Root Cause On September 16, 2026, our upstream service experienced a major global service disruption affecting multiple production instances worldwide. This was a significant outage, impacting their customers globally. While the provider's outage was global in scope, its effect on Customer Portal was intermittent: a subset of API calls failed while the majority continued to succeed. Customer Portal services rely on this service provider as the source of truth for support cases, user/contact information, and account data. As a result, the disruption to the service provider’s APIs led to failures and degraded performance across all dependent functionalities. --- ## Detection The issue was detected automatically through our monitoring system within minutes of the first customer-facing error. The first customer-facing errors were observed at 8:15 am UTC on September 16, 2026, and an automated alert for Customer Portal fired at 8:17 am UTC. Because the failures were intermittent, with a portion of API calls continuing to succeed, the impact initially presented as sporadic errors rather than a clear, sustained outage. The upstream service provider publicly acknowledged the outage on their status page shortly afterward (at approximately 8:33 am UTC), confirming the root cause. --- ## Response Because the errors were intermittent, the initial period was spent confirming that the sporadic failures represented an upstream provider outage rather than a transient blip. At 9:14 am UTC, we published a public status update identifying degraded Customer Portal performance caused by the ongoing upstream outage. Based on our own monitoring, Customer Portal error rates returned to normal by approximately 12:00 pm UTC, after which no further customer-facing failures were observed. Because the upstream provider's incident remained unresolved, we kept the public incident open and continued to post regular status updates (10:21 am, 11:29 am, 12:29 pm, 1:29 pm, 2:31 pm, 3:34 pm, and 4:51 pm UTC) while validating stability, until the upstream outage was fully resolved. --- ## Follow-Up Since the disruption originated entirely within the upstream service provider, 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 Sep 11, 2026, 07:47 PM UTC· resolved Sep 11, 2026, 09:33 PM UTC

1. identified Sep 11, 2026, 07:47 PM UTC

   Some customers will not be unable to deploy solution packages. Issue is identified and fix rollout is in progress. Start time: 15:18 UTC

2. identified Sep 11, 2026, 07:52 PM UTC

   Some customers will not be unable to deploy solution packages. Issue is identified and fix rollout is in progress. Start time: 15:18 UTC

3. monitoring Sep 11, 2026, 08:49 PM UTC

   Fix Rollout completed in all regions. We are currently monitoring. Start time: 15:18 UTC

4. resolved Sep 11, 2026, 09:33 PM UTC

   Issue is resolved.Start time: 15:18 UTC End time: 20:45 UTC

5. postmortem Sep 22, 2026, 09:59 AM UTC

   ## Customer impact Between September 11, 2026 at 14:56 UTC and September 11, 2026 at 20:45 UTC, a subset of customers could not deploy solution packages in Solutions Management. Deployment attempts failed during package generation with a compatibility error indicating that a package version was not compatible with the expected Application runtime version. The impact was global across production environments and lasted approximately 5 hours and 27 minutes. Community environments experienced related impact beginning at 14:56 UTC. ## Root cause A regression in an internal component that manages software package versions caused the failure. During solution package generation, this component provided an incompatible package version, which caused a framework compatibility check to fail and blocked affected deployments. ## Detection The issue was first reported by a customer and then reproduced internally. The incident was created. The team confirmed the failure as a package compatibility error. ## Response At 18:42 UTC, the team identified the deployment error as a compilation failure caused by an incompatible package version. The mitigation strategy was to restore the affected component to a previously known-good version. The restore began taking effect by 18:50 UTC. By 19:16 UTC, monitoring data confirmed the restore was progressing and the incompatible version was clearing. At 19:47 UTC, the public status page was updated to reflect that the issue was identified and the fix was in progress. Recovery was slower than initially expected because the restored component is only loaded when customers restart their designer session, rather than immediately upon deployment. The restore completed across all regions at 20:45 UTC. The incident was marked resolved after monitoring confirmed recovery. ## Follow up - Short-term, delivered. Keep files in cache for every runtime version in use rather than only the newest, so a rebuild would no longer delete files robots depend on. - Short-term, to do. Add automated end-to-end test coverage to the deployment pipeline that validates package cache integrity before rollout, blocking releases when tests fail. - Short-term, to do. Add automated monitoring and alert to cover NuGet package cache missed that fail to be resolved either from cache or from the source. - Longer-term, in progress. Stored dependency results are now validated against their cache and discarded when referenced files are missing, so a stale result can't be reused against a mismatched cache — jobs fall back to downloading at run time rather than failing.

Read the full incident report →