UiPath Outage History

Started Sep 10, 2026, 02:34 PM UTC· resolved Sep 10, 2026, 03:41 PM UTC

1. resolved Sep 10, 2026, 03:40 PM UTC

   Issue is mitigated now. Cloudflare had DNS update delays during this time briefly for 9 minutes. Multiple Services were impacted due to this in Korea and Japan causing 520 errors. Incident link: https://www.cloudflarestatus.com/incidents/nhfcmzd1pv4p

2. postmortem Sep 24, 2026, 01:27 PM UTC

   ## Customer impact Between 2:34 pm UTC and 2:43 pm UTC on September 10, 2026, customers in Japan and Korea experienced failures when accessing multiple UiPath Automation Cloud services. Affected requests returned HTTP 520 errors. The impact lasted approximately nine minutes and affected Orchestrator, Apps, authentication, and other platform services in the region. ## Root cause Our upstream cloud service provider performed unplanned maintenance, which resulted in a decreased availability of resources which UiPath Automation Cloud relies on. Once the maintenance completed, services recovered almost immediately. ## Detection Our engineering team detected the issue through automated service monitoring and began investigating at 3:18 pm UTC on September 10, 2026. This was 44 minutes after impact began and 35 minutes after the affected window had already ended. By the time our team reviewed monitoring data, the failures had stopped and services had recovered. ## Response At 3:19 pm UTC, the incident was classified as customer-impacting and presumed to be correlated to an active incident at our DNS provider. By 3:31 pm UTC, our team confirmed that HTTP 520 errors were being returned for traffic originated from Japan and Korea. Further investigation pointed that the root cause of the issue was not at the DNS layer but at our routing infrastructure layer. A support case was opened with the cloud service provider, which confirmed the root cause as being unplanned maintenance on their part. At 3:35 pm UTC, a customer status page update was initiated. At 3:40 pm UTC, the status page update was published documenting the nine-minute impact window and attributing the cause to a third-party DNS delay. The incident was marked resolved at 3:41 pm UTC after monitoring confirmed no continuing failures. ## Follow up 1. We are evaluating follow-up actions based on this event and similar past incidents involving cloud infrastructure and network behavior, including improvements to reduce the time between the start of an externally caused outage and our team's awareness of it as well as increasing the capacity of our routing layer to make it more resilient.

Read the full incident report →

Started Sep 10, 2026, 10:00 AM UTC· resolved Sep 10, 2026, 06:08 PM UTC

1. resolved Sep 11, 2026, 01:18 PM UTC

   On 10 September 2026 between 10:00 UTC and 17:23 UTC , Subset of customers in the Europe region experienced elevated failure rates for robot jobs due to an issue with the package cache used by the robot executor. The issue has been resolved and the fault rate has returned to baseline levels. Further details will be provided in the RCA.

2. postmortem Sep 21, 2026, 08:10 AM UTC

   ## Customer Impact On September 10, 2026, between 10:00 UTC and 17:40 UTC, customers using Automation Cloud in Europe region experienced intermittent failures of unattended robot job executions on the serverless runtime. Affected jobs failed shortly after starting, before any automation work was performed, with errors indicating that a required program file could not be found. Only automations using a specific set of software libraries were affected; the majority of jobs in the region continued to run normally. The job failure rate rose from a normal baseline of approximately 6% to a peak of 30-37%, and approximately 312 job executions failed that would otherwise have succeeded. Affected automations could be re-run successfully once the issue was resolved. No data was lost, and no job produced incorrect results. ## Root Cause To make automations start quickly we keep a pre-built cache of commonly used software packages, so robots do not download them at run time. Two changes combined to cause this incident. A routine update to an internal build tool changed which Application runtime version the cache was built for. Packages ship files for several runtime versions and the cache keeps only those needed, to stay a manageable size; after the update it kept only the newest runtime's files and deleted the ones our robots use. Separately, we store previous dependency calculations so repeat jobs start faster. Those stored results pointed at the deleted files, and the check validating them confirmed only that the package folder existed, not its contents. The folders were intact and the correct size, so the check passed, the stale result was reused, and the step that would have caught the missing files was skipped. Affected jobs were handed a path that no longer existed and failed on startup. Without the second factor the robot would simply have downloaded the package at run time - slower, but not a failure. That is what happened in every other region, where the same cache was in use but this optimisation was not enabled; it was on only in Europe region, which is why impact was confined there. ## Detection The issue was not detected by automated monitoring. It was identified after a customer-reported support case. Three gaps contributed, all addressed below: there was no alert on elevated job failure rate per region, so a sustained rise from 6% to over 30% went unnotified for more than seven hours; the cache build had no validation that the files required by the robot runtime survived the size-reduction step, so it completed successfully and deployed automatically; and existing cache integrity checks verify that packages are present and record their sizes, which all passed, because every package was present at full size and only files inside them were missing. ## Response All times UTC on 10 September 2026. * **09:37 and 09:49 - the newly built cache became active in the region.** * **10:00 - customer job failures begin.**Following the customer report, engineering identified that the failures were caused by files missing from the package cache, and traced the change that removed them. * **17:12 - mitigation begins; the cache is rolled back to the last version built before the change.** * **17:23 - the rolled-back cache becomes active.** * **17:40 - failure rate returns to normal. Customer impact ends.** * **17:46 - the stored-result optimisation is disabled as a secondary safeguard, so that even a faulty cache would slow job starts rather than fail them.** * **18:08 - the rollback completes across the region.** Later that evening - the automated cache build pipeline was disabled, preventing a new cache from reintroducing the problem before a permanent fix is in place. Recovery was verified by confirming that jobs starting after the rollback took effect returned to the region's normal failure rate, rather than inferring recovery from the overall rate subsiding. ## Follow-up * Short-term, delivered. The cache now keeps the files for every runtime version in use, instead of keeping only the newest and discarding the rest. This removes the condition that caused the incident, because a cache rebuild can no longer delete files that robots depend on. The capability was added on 11 September and switched on for both runtime versions on 14 September. * 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 validated against their cache and discarded if referenced files are missing. Stale results won't be reused against a mismatched cache — if files are missing, jobs fall back to downloading at runtime instead of failing. This optimization will be rolled out gradually to verify and deliver the work. * A related recurrence of the same underlying cause affected solution publishing on 11 September and was mitigated the same day; it is tracked separately. The fixes above address the common cause and are intended to prevent recurrence of both in any deployment region.

Read the full incident report →

Started Sep 03, 2026, 03:34 PM UTC· resolved Sep 03, 2026, 04:17 PM UTC

1. investigating Sep 03, 2026, 03:34 PM UTC

   We are currently investigaing the issue

2. identified Sep 03, 2026, 03:39 PM UTC

   The issue was identified, and the appropriate mitigation measures were implemented to address it.

3. monitoring Sep 03, 2026, 03:47 PM UTC

   The issue has been successfully resolved, and the service has been fully restored. The service is operating normally at this time.

4. resolved Sep 03, 2026, 04:17 PM UTC

   The issue has been successfully resolved, and the service has been fully restored. The service is operating normally at this time.

5. postmortem Sep 25, 2026, 11:11 AM UTC

   ## Customer impact Between approximately 3:20 pm UTC and 3:40 pm UTC on September 3, 2026, some customers using Document Understanding in the US experienced failed document processing requests. Affected requests returned service unavailable errors, and some extraction and processing calls did not complete successfully. The impact lasted approximately 20 minutes and was limited to Document Understanding in the US region. ## Root cause A scheduled backend deployment supporting Document Understanding triggered a rolling update of service instances in the US region. During this process, replacement instances could not start promptly because the required compute resources were temporarily occupied by other workloads. Because the affected service was already handling heavy traffic, the temporary reduction in available instances caused some requests to be rejected with service unavailable errors. ## Detection An automated failed-requests alert detected the issue at 3:19 pm UTC on September 3, 2026. The alert was escalated immediately, and the incident was declared customer-impacting at 3:20 pm UTC. Detection occurred within approximately one minute of the start of customer impact. ## Response By 3:22 pm UTC, responders joined the incident response call and began coordinating mitigation. At 3:34 pm UTC, a public status update confirmed that investigation was in progress. By 3:39 pm UTC, the cause had been identified and mitigation steps were underway. To restore service, the team paused automatic scaling for the affected service, restored it to its full instance count, and temporarily reduced lower-priority workloads to free compute resources. The service returned to full capacity by 3:40 pm UTC, and failed requests dropped to zero. The incident was confirmed mitigated at 3:47 pm UTC and resolved at 4:17 pm UTC after continued monitoring showed the service operating normally. ## Follow up 1. We are pausing further deployments that could trigger the same capacity reduction until a scheduling fix is in place. 2. We are implementing stricter workload placement rules to ensure Document Understanding service instances are not blocked by other workloads during future deployments. 3. Introduce per-tenant GPU usage limits so that a single workload of very large documents cannot saturate shared capacity for other customers. 4. Return accurate retry guidance on overload responses and propagate it through Document Understanding's internal layers, and make the reduced internal retry policy permanent in configuration. 5. Add leading-indicator alerting on request duplication and worker saturation, and an operational runbook for this overload pattern, so it is recognised before customers are affected.

Read the full incident report →

Started Sep 02, 2026, 07:59 PM UTC· resolved Sep 03, 2026, 04:30 PM UTC

1. resolved Sep 04, 2026, 05:48 PM UTC

   The Insights dashboard in Looker experienced an issue that prevented the latest Maestro runs, from appearing in the dashboard Impacted regions : US, SEA, IND, CA, AUE,JP ,UK Incident timeline Started: September 2, 2026 at 20:00:00 UTC Resolved: September 4, 2026 at 16:30:00 UTC The issue has been currently resolved, and the Insights dashboard is displaying the latest Maestro run data.

2. postmortem Sep 17, 2026, 10:13 PM UTC

   ## Customer impact Between September 2, 2026 at 7:59 pm UTC and September 4, 2026 at 4:30 pm UTC, the Insights dashboard did not display Maestro process runs created after the start of the affected window. The underlying data was never lost. It was held safely in our staging layer and became visible once processing resumed. The United States, Singapore, India, Canada, Australia, Japan, and United Kingdom regions were affected, with the exact duration varying by region from approximately 24.6 hours to 44.5 hours. The European Union region hit the same failure but recovered on its own within about 45 minutes, as described under Response below. Element-level Maestro data continued to update normally throughout, so the dashboard remained usable and did not appear broken; what was affected was the count and listing of recent process runs. ## Root cause A data processing task that moves Maestro process-run records from our staging layer into the database serving the Insights dashboard stopped running. The cause was a deployment sequencing problem. Two related changes are delivered by two separate deployment pipelines: one adds a new field to the staging layer, the other updates the processing task that reads it. In production the second pipeline ran approximately two hours before the first. The updated task therefore referenced a field that did not exist yet, and it failed on each scheduled run. Our data platform automatically suspends a task after a number of consecutive failures, which it did. The missing field was added shortly afterwards, but a suspended task does not resume on its own, so processing stayed stopped until we resumed it manually. Our pre-production environments received the same two changes in the correct order, so this condition never appeared there. ## Detection Our monitoring did detect the task failures automatically, within 2 to 10 minutes of the first failure in each region, and notified our on-call team. That notification then cleared on its own. The alert measures how often the task is failing, and once the platform suspended the task it stopped running altogether and therefore stopped reporting failures. The signal returned to normal while the data was still not moving. As a result the condition was not escalated at the time, and the full extent of the delay was identified after a customer reported the missing data on the morning of September 4. A formal incident was declared later that day. ## Response After the customer report, our engineering team traced the delay to the suspended processing task within about an hour and resumed it for the first affected region immediately. We then reviewed each production region that received this deployment, one at a time, resumed the task in each affected one, and verified recovery in each case by confirming three things: the task was running again, the dashboard database had caught up to the staging layer, and no delayed records remained. All 123,090 delayed records were replayed automatically on resume. No manual data reconstruction or backfill was required, because the task resumes from where it stopped rather than from the current time. Recovery was complete across all affected regions by 4:30 pm UTC on September 4. The European Union region experienced the same failure but recovered on its own, because the missing field was added before that region's task reached the suspension threshold. Its data was delayed by up to 45 minutes. We published a status page notice the same day, after recovery had completed. For an incident of this shape, where data is delayed rather than unavailable, that notice came later than it should have. We have added a follow-up item to communicate during such incidents rather than after them. ## Follow up 1. The field referenced by the deployment has been applied in every production region affected by this incident, so this specific failure cannot recur there. 2. We have extended an existing data-freshness monitor to cover Maestro process-run data. Unlike the alert that fired during this incident, this signal measures how far behind the dashboard database is and therefore stays raised for as long as a delay persists, rather than clearing when processing stops. The change is merged and is being deployed to production regions. 3. We are adding a monitor that reports when one of these processing tasks is no longer running at all, which is the specific state that went unobserved here. 4. We are adding a deployment safeguard so that a processing task cannot be deployed before the staging change it depends on, and making that dependency explicit between the two pipelines rather than relying on their ordering. 5. We are adding a post-deployment verification step that checks data movement in each production region individually, since these deployments roll out region by region. 6. We are updating our customer-communication guidance for delayed-data incidents, so that a status page notice is published while data is still delayed rather than after recovery. 7. We consider this the most important finding of this incident: the monitoring existed and was correct, but it measured the failure event rather than the state that actually affected customers. 8. We are also reviewing our alerting more broadly against the principle this incident demonstrated: an alert should track the condition that affects customers, not only the event that causes it, because the two do not last the same amount of time.

Read the full incident report →

Started Sep 01, 2026, 01:49 PM UTC· resolved Sep 01, 2026, 03:06 PM UTC

1. investigating Sep 01, 2026, 01:49 PM UTC

   We are investigating reports of degraded performance impacting digitization and extraction for Document Understanding and IXP in US. Impact: Users may experience slowness and failed Document Understanding runtime operations. Our teams are working to identify the cause and will share more details as the investigation progresses.

2. monitoring Sep 01, 2026, 02:07 PM UTC

   We have identified the issue and applied a mitigation. Services are returned back to healthy state and we are monitoring the services.

3. resolved Sep 01, 2026, 03:06 PM UTC

   This issue has been fully resolved and services are stable now. We'll post more details of the incident to status page soon.

4. postmortem Sep 15, 2026, 11:08 AM UTC

   ## Customer impact On September 1, 2026, between 10:00 UTC and 15:06 UTC, customers using Document Understanding in the US region experienced severe delays in document digitization, the step that converts uploaded files into machine-readable text. Document Understanding and IXP operations that depend on digitization were affected in the same way. Digitization times increased substantially compared to normal, and a backlog of 15,000 to 20,000 queued jobs built up before being fully processed. ## Root cause The issue was caused by a significant increase in digitization traffic in the US region, which exceeded the capacity of the database that distributes digitization work to processing workers. This database had operated reliably at its existing size for several years; the recent growth in traffic pushed it beyond its limits. Once saturated, the database could hand out work far more slowly than incoming demand required, so a backlog accumulated for as long as demand exceeded that rate. ## Detection Automated internal checks on a dependent service detected the slowdown, and the incident was opened at 13:33 UTC. ## Response Our engineering team identified the work-distribution database as the cause by 13:33 UTC and increased its capacity at 13:40 UTC. As a consequence, the backlog cleared between 13:45 and 14:00 UTC, impact was mitigated at 14:07 UTC, and processing times were back to normal at 15:06 UTC. The service has operated normally since. ## Follow up 1. We have increased the capacity of the affected database and are reviewing capacity headroom across all databases supporting this service, in all regions, against current and projected volume. 2. We are tuning our automated alerting so that sustained high load and processing delays are detected and escalated earlier, before they become customer-visible. 3. We are reviewing and optimizing the indexes on the databases supporting this service so that queries remain efficient as data volume grows.

Read the full incident report →

Started Aug 31, 2026, 04:54 PM UTC· resolved Aug 31, 2026, 07:39 PM UTC

1. investigating Aug 31, 2026, 04:55 PM UTC

   We are currently investigation the issue.

2. identified Aug 31, 2026, 05:07 PM UTC

   We have identified the issue and implemented the necessary fix

3. monitoring Aug 31, 2026, 06:24 PM UTC

   The issue has been mitigated, and the service is currently operational. We will continue to closely monitor the service health and take further action if needed.

4. resolved Aug 31, 2026, 07:39 PM UTC

   The issue has been mitigated, and the service is currently operational. We will continue to closely monitor the service health and take further action if needed.

5. postmortem Sep 17, 2026, 09:29 PM UTC

   ## Customer impact Between August 31, 2026 at 3:40 pm UTC and September 1, 2026 at 12:00 am UTC, a subset of customers using Document Understanding custom-model extraction and classification in the US regions experienced intermittent request failures (HTTP 503 "Server overloaded") and slow processing. The impact was limited to document extraction requests served by custom models. It manifested in five waves of roughly twenty to forty minutes each, the heaviest between 5:10 pm and 5:50 pm UTC. During a wave the majority of requests to the affected models were rejected; between waves most requests completed normally. Document Understanding retried failed requests automatically, so most documents completed after a delay. A small share of documents submitted during the waves did not complete within the incident window and had to be resubmitted. No data was lost or exposed, and no incorrect results were returned. Extractions that appeared to return empty results, or remained in Running, were client-side timeouts inside the incident window ## Root cause Two independent defects combined under an ordinary volume of traffic. The first was in our request de-duplication mechanism. A small number of very large documents occupied shared GPU capacity and slowed all processing on the affected pool, so ordinary documents began exceeding their processing deadline. When a request's deadline expired, the de-duplication layer treated the work as abandoned even though the worker was still processing the document. The automatic retry of that request was then admitted to a worker, where it correctly avoided reprocessing the document but waited for the original result while holding a unit of worker capacity. With several retries waiting per hot document, the workers ran out of capacity and rejected unrelated requests. Each rejection told clients to retry after five seconds, and Document Understanding's internal services also retried, which kept the workers saturated. The second was in the shared result cache used to serve repeated requests without recomputation. A configuration defect had left the cache running at its storage limit since early August; in that state it acknowledged some writes and then discarded them. Documents that had already been processed successfully were therefore recomputed when retried, which added real processing load and restarted the cycle after each wave subsided. ## Detection Automated monitoring detected the failures at 4:10 pm and 4:14 pm UTC on August 31, approximately 34 minutes after the first rejections. Engineers began investigating at 4:32 pm UTC, a customer-impacting incident was declared at 4:47 pm UTC, and a public status page notice was posted at 4:55 pm UTC. ## Response At 4:38 pm UTC, GPU capacity was freed by scaling down idle workloads, which reduced the failure ratio from approximately 78% to approximately 50%. Automatic scaling of the affected pool had reached its configured maximum by 5:15 pm UTC. Additional capacity was freed at 5:21 pm UTC when a second wave began. At 5:26 pm UTC the investigation established that total request volume was rising while the number of distinct documents was flat, indicating retry amplification rather than new customer load. At 5:44 pm UTC an internal retry layer was reduced to a single attempt, and by 5:59 pm UTC request volume had converged with the number of distinct documents. The same change was applied to the delayed US environment by 7:12 pm UTC. The status page was moved to monitoring at 6:24 pm UTC and to resolved at 7:39 pm UTC. Failures recurred in three further, smaller waves at approximately 6:30 pm, 8:20 pm and 10:50 pm UTC as new large documents arrived, and cleared by 12:00 am UTC on September 1 once those documents completed and evening load declined. A detailed analysis on September 2 identified the result cache defect. The cache configuration was corrected at 3:15 pm UTC on September 2, which stopped the loss of completed results, and further tuning on September 9 removed a remaining write stall; no discarded writes have been observed since. ## Follow up 1. Improve the request de-duplication mechanism so duplicate requests are rejected before they consume worker capacity. The new implementation is complete and its rollout to production is in progress. 2. Result cache: capacity sizing for the US working set, explicit error reporting when a write cannot be stored, and monitoring and alerting on cache health. The configuration fix is deployed. 3. Introduce per-tenant GPU usage limits so that a single workload of very large documents cannot saturate shared capacity for other customers. 4. Return accurate retry guidance on overload responses and propagate it through Document Understanding's internal layers, and make the reduced internal retry policy permanent in configuration. 5. Add leading-indicator alerting on request duplication and worker saturation, and an operational runbook for this overload pattern, so it is recognised before customers are affected. Customers processing very large documents are encouraged to use asynchronous submission where available and to honour the `Retry-After` header on 503 responses.

Read the full incident report →

Started Aug 28, 2026, 03:41 PM UTC· resolved Aug 28, 2026, 10:57 PM UTC

1. identified Aug 28, 2026, 03:41 PM UTC

   We have identified the root cause of the degraded performance and we are in the process of deploying a fix in the coming hours. Customers are experiencing issues in accessing queue item details panels due to a regression in the UI. API surface is unaffected. Additional updates will be provided as we move toward resolution.

2. monitoring Aug 28, 2026, 05:27 PM UTC

   We have identified the root cause of the degraded performance and we are in the process of deploying a fix in the coming hours. It affects linked queries where the user does not have access to the original folder. API surface is unaffected. Export via CSV can be used as a workaround.Additional updates will be provided as we move toward resolution.

3. identified Aug 28, 2026, 05:39 PM UTC

   We have identified the root cause of the degraded performance and we are in the process of deploying a fix in the coming hours. It affects linked queries where the user does not have access to the original folder. API surface is unaffected. Export via CSV can be used as a workaround. Additional updates will be provided as we move toward resolution.

4. identified Aug 28, 2026, 08:00 PM UTC

   The fix is currently being applied. We will provide another update shortly once the deployment has been completed across all affected regions.

5. resolved Aug 28, 2026, 10:57 PM UTC

   The fix has been successfully deployed across all regions, and we have validated that the issue is resolved. The service is operating as expected.

6. postmortem Sep 03, 2026, 08:49 AM UTC

   ## Customer impact Between August 28, 2026 at 3:23 pm UTC and August 28, 2026 at 10:57 pm UTC, a subset of customers experienced errors when opening queue item details panels in Orchestrator. The affected path returned a 404 page for LINKED queues when the user did NOT have access to the original folder in which the items were created. The impact affected only Orchestrator UI interactions and it spanned across all regions running the affected software version. Orchestrator application programming interface access was unaffected, and exporting queue data to CSV was available as a workaround. The total duration was approximately 7 hours. ## Root cause The incident was caused by a regression in the Orchestrator user interface for linked queues accessed from other folders. The regression did not correctly handle the linked-queue details flow when the requesting user lacked access to the original folder, which caused the queue item details panel to route to a 404 page instead of displaying the expected information. ## Detection The issue was detected through an automated incident alert for the Orchestrator front end on August 28, 2026 at 3:23 pm UTC. ## Response At 3:31 pm UTC on August 28, 2026, our engineering team described the issue as customers being unable to access queue item details panels due to a regression. At 3:41 pm UTC, a public status update confirmed that the root cause had been identified, that a fix was being deployed, and that application programming interface access was unaffected. At 5:27 pm UTC, the scope was narrowed to linked queues where the user did not have access to the original folder. At 5:29 pm UTC, the team determined that the initial fix did not fully address the affected scenario, and a corrected fix was developed. At 5:30 pm UTC, the affected scenario was reproduced and the corrected fix was validated locally. At 5:39 pm UTC, a status page update documented CSV export as a workaround. Deployment of the corrected fix continued across affected regions. At 10:50 pm UTC, the fix was confirmed deployed everywhere. At 10:57 pm UTC, the incident was marked resolved and the status page was updated to confirm the service was operating as expected. ## Follow up Formal follow-up actions are being tracked through the post-incident review process initiated at resolution. ## Action items - Expanding our automated test cases to include this scenario, and other similar scenarios related to linked objects or cross-folder scenarios. - Ensuring we can safely turn off any changes via a flag for a faster response time.

Read the full incident report →

Started Aug 27, 2026, 05:16 PM UTC· resolved Aug 27, 2026, 09:57 PM UTC

1. investigating Aug 27, 2026, 05:16 PM UTC

   We are investigating reports of missing robot logs in the US region. Our teams are working to identify the cause and will share more details as the investigation progresses.

2. identified Aug 27, 2026, 06:53 PM UTC

   We identified that robot logs ingestion was delayed. Robot logs are catching up to live data and we are monitoring recovery.

3. monitoring Aug 27, 2026, 08:31 PM UTC

   Logs are now populating as expected in real time and we will continue monitoring the application.

4. resolved Aug 27, 2026, 09:57 PM UTC

   The issue has been resolved and logs are populating as expected.

5. postmortem Sep 09, 2026, 06:33 AM UTC

   ## Customer impact Between August 27, 2026 at 5:00 pm UTC and August 27, 2026 at 8:30 pm UTC, robot logs in UiPath Orchestrator were delayed and, for some customers, did not appear in the logs view as expected. The customer-facing impact lasted for approximate 3 hours and 30 minutes. A subset of customers in the US region were affected. Automation execution remained available, but customers could not reliably view recent robot log entries until ingestion caught up. Jobs continued to run normally, and all logs generated during the incident were durably retained throughout. ## Root cause Robot logs flow through a durable ingestion stream and are indexed into the search store that powers Orchestrator's log views by a dedicated indexing tier. During the incident, some indexing consumers stopped making progress: logs continued to be received and safely stored, but a portion were no longer being indexed for display. The indexing processes remained running and continued to pass automated health checks, so the platform's self-healing mechanisms did not trigger. Because the corrective restart also cleared the components' internal state, the exact trigger of the blockage could not be conclusively determined from retained telemetry. The behavior is consistent with a known failure mode of the third-party component involved, in which stream consumers can silently stop consuming after a transient error without crashing. An internal data processing and transport component within the log indexing tier became blocked. No customer-facing component failed, and there was no performance degradation of the platform itself. The impact was limited to delayed visibility of robot logs in Orchestrator. ## Detection The issue was detected through customer reports of robot logs not displaying across tenants. The incident was declared at August 27, 2026 at 5:00 pm UTC, and the public status page was updated at 5:16 pm UTC with an initial investigation notice. No automated alerting detected the log processing stoppage — the issue was surfaced entirely through customer complaints. This represents a monitoring gap for this specific scenario that our engineering team is already working on. ## Response At 5:16 pm UTC on August 27, 2026, we posted a status update that we were investigating reports of missing robot logs in the US region. Our engineering team investigated several potential causes: the log storage cluster was confirmed healthy with all indexes intact, message queue throughput was confirmed stable, and log submission rates were normal. The investigation narrowed the issue to the log processing nodes, which had stopped ingesting data for certain groups of tenants. A restart of the affected log processing services was identified as the appropriate fix. After initial restarts showed immediate improvement, the team expanded restarts to all log processing services across the US region. By 6:53 pm UTC, all restarts were confirmed complete and the status page was updated to note that robot logs were catching up to live data. By 7:59 pm UTC, ingestion was confirmed fully up to date. At 8:30 pm UTC, the status page was updated to reflect that logs were populating in real time and the team was continuing to monitor. At 9:57 pm UTC, the incident was marked resolved. ## Follow up 1. Ingestion-lag monitoring and alerting, paging our engineering team within minutes of any indexing delay, ahead of customer-visible impact. 2. An updated rapid-mitigation runbook, so any residual manual intervention is executed within minutes. 3. Migration of the ingestion infrastructure to our next-generation deployment platform, which keeps the underlying components on current, vendor-supported versions, picking up upstream fixes and reliability improvements for the affected component.

Read the full incident report →

Started Aug 25, 2026, 09:41 AM UTC· resolved Aug 25, 2026, 10:12 AM UTC

1. identified Aug 25, 2026, 09:41 AM UTC

   We have identified an issue affecting the Solution Deployment feature in Studio Web in the Japan region, where solution deployments may fail. A fix has been prepared and will be rolled out shortly. We will provide further updates as more information becomes available.

2. monitoring Aug 25, 2026, 09:47 AM UTC

   The fix has been successfully deployed in the Japan region, and the issue has been mitigated. We are closely monitoring the service to ensure Solution Deployment continues to operate as expected and will provide further updates as needed.

3. resolved Aug 25, 2026, 10:12 AM UTC

   The issue has been resolved, and Solution Deployment in Studio Web is operating as expected in the Japan region. No further impact has been observed.

4. postmortem Sep 16, 2026, 08:19 AM UTC

   ## Customer impact Between August 25, 2026 at 9:30 am UTC and August 25, 2026 at 10:13 am UTC, Solution Deployment in Studio Web was unavailable for customers in the Japan region. Affected customers could open Studio Web but were unable to use the deploy feature. The entire Japan region was affected. The incident lasted 42 minutes. Service mitigation was confirmed at August 25, 2026 at 9:47 am UTC, and full resolution was confirmed at August 25, 2026 at 10:13 am UTC after monitoring showed no further impact. ## Root cause A required deployment update for the Solution Deployment service had not been applied to the Japan region, leaving it on an outdated version. This prevented the deploy feature in Studio Web from operating correctly for customers in that region. ## Detection The issue was first detected by a customer on august 25, 2026 at 9:30 AM UTC. The customer raised a support issue, and an incident was then created from it. ## Response By August 25, 2026 at 9:36 am UTC, investigation confirmed that the Japan region had not received the required Solution Deployment update and was running an outdated version. A fix was already being prepared. The public status page was updated at August 25, 2026 at 9:41 am UTC to reflect the identified issue and that a fix was being rolled out. At August 25, 2026 at 9:44 am UTC, manual testing confirmed the fix was deployed and working. At August 25, 2026 at 9:47 am UTC, the status page was moved to monitoring. Full recovery was confirmed at August 25, 2026 at 10:13 am UTC, with Solution Deployment operating as expected and no further impact observed. ## Follow up 1. Add documentation and protocols for the frontend framework version upgrade process 2. Add canary tests for both services 3. Add automation that closes the deploy ticket only after everything is verified as working

Read the full incident report →

Started Aug 25, 2026, 03:58 AM UTC· resolved Aug 25, 2026, 04:53 AM UTC

1. investigating Aug 25, 2026, 03:58 AM UTC

   We are investigating an issue affecting customers using Insights in the Singapore region, where dashboards may fail to load and display timeout errors. Our teams are working to identify the root cause and will provide further updates as more information becomes available.

2. monitoring Aug 25, 2026, 04:37 AM UTC

   The issue has been mitigated, and we are closely monitoring the Insights service in the Singapore region to ensure dashboards continue to load as expected.

3. resolved Aug 25, 2026, 04:53 AM UTC

   The issue has been resolved, and the Insights service in the Singapore region is operating as expected. No further impact has been observed.

4. postmortem Sep 04, 2026, 11:46 AM UTC

   ## Customer impact Between August 25, 2026 at 3:42 am UTC and August 25, 2026 at 4:53 am UTC, customers using Insights in the Singapore region experienced failures loading Insights dashboards. Affected users saw dashboard pages time out or fail to load, and server errors were observed for related service requests. The primary impact was to Insights dashboard access, including charts and alerts. A related backend service also returned server errors during the incident, but dashboard access had recovered before final resolution. ## Root cause The incident was attributed to a regional Microsoft service disruption in Singapore affecting infrastructure used by the Insights service. During the disruption, the Insights service was unable to reliably serve dashboard requests, resulting in request timeouts and server errors. No changes were made on our side. The service recovered as the Microsoft regional disruption was resolved, and Microsoft subsequently reported a Singapore regional service issue on its status page. A formal root cause analysis has been requested from Microsoft to confirm the specific failure mechanism and identify any additional preventive or mitigation measures. ## Detection Automated health monitoring for the Insights service detected the issue at August 25, 2026 at 3:42 am UTC. Customer impact was confirmed on the response bridge shortly after detection. ## Response At August 25, 2026 at 3:58 am UTC, we posted a public status update noting that Insights dashboards in the Singapore region might fail to load and display timeout errors. During the response, our engineering team verified server errors in automated monitoring, attempted to access service diagnostics, and began a recovery procedure on the underlying infrastructure. At August 25, 2026 at 4:01 am UTC, the Insights service recovered while the recovery procedure was in progress, and dashboard loading was validated across multiple test accounts. At August 25, 2026 at 4:37 am UTC, we moved the incident to monitoring after confirming dashboards loaded successfully. A related backend service recovered at August 25, 2026 at 4:49 am UTC, and the incident was marked resolved at August 25, 2026 at 4:53 am UTC. ## Follow up 1. Request a root cause analysis from Microsoft for the Singapore regional disruption affecting the insights dashboards loading issue.

Read the full incident report →

Started Aug 25, 2026, 03:44 AM UTC· resolved Aug 25, 2026, 04:59 AM UTC

1. investigating Aug 25, 2026, 03:44 AM UTC

   We are investigating an issue affecting customers using the Extended OCR functionality in the Document Understanding service in the Singapore region. Our teams are working to identify the root cause and will provide further updates as more information becomes available.

2. monitoring Aug 25, 2026, 04:04 AM UTC

   The issue has been mitigated, and we are closely monitoring the service to ensure it continues to operate as expected. We will provide further updates as more information becomes available.

3. resolved Aug 25, 2026, 04:59 AM UTC

   The issue has been resolved, and the service is operating as expected. No further impact has been observed.

4. postmortem Aug 27, 2026, 03:42 AM UTC

   ## Customer impact On August 25, 2026, Extended OCR requests in the Document Understanding service failed with 500 status code in the Singapore region for approximately 33 minutes, between 03:08 and 03:41 UTC. The cause was a Microsoft regional service disruption in Singapore. All other Document Understanding functionality was unaffected, and no other region was impacted. ## Root cause The failure was attributed to a regional Microsoft service disruption in Singapore affecting resources used by the Extended OCR capability. No changes had been made on our side, and Microsoft subsequently updated their own status page to reflect a Singapore regional issue. A formal root cause analysis has been requested from Microsoft. ## Detection An automated alert for the Document Understanding service fired on August 25, 2026 at 3:13 am UTC. The alert was acknowledged promptly, and the incident was declared customer-impacting within minutes. ## Response The on-call engineer scoped the impact to the Singapore region. Responders ruled out a recent service update as the cause, as the same update had been deployed to other regions with no comparable impact, which pointed to a regional dependency failure outside our infrastructure. Because the failure originated in an upstream Microsoft service, no mitigating action was available or required on the UiPath side. Requests began succeeding again at 03:41 UTC as the Microsoft dependency recovered. Responders held the incident open to verify sustained recovery: ten minutes of clean traffic were confirmed at 03:51 UTC, the incident moved to Monitoring at 04:04 UTC, and it was resolved at 04:59 UTC after continued stability with no further failures. ## Follow up 1. Requested a root cause analysis from Microsoft for the Singapore regional disruption affecting Extended OCR dependencies, including how recurrence can be prevented.

Read the full incident report →

Started Aug 24, 2026, 10:43 AM UTC· resolved Aug 24, 2026, 11:55 AM UTC

1. identified Aug 24, 2026, 10:43 AM UTC

   We have identified the cause of an issue impacting a small number of customers using UiPath Apps authored from the Studio Web service across multiple regions. Our teams are ready with a fix, and deployment is about to begin across the affected regions. We will continue to monitor the deployment and provide further updates as the fix takes effect.

2. monitoring Aug 24, 2026, 11:30 AM UTC

   The fix has been successfully deployed across all affected regions, and the issue has been mitigated. We are closely monitoring the service to ensure the fix continues to perform as expected and will provide further updates as needed.

3. resolved Aug 24, 2026, 11:55 AM UTC

   The issue has been resolved, and the service is operating as expected. No further impact has been observed.

4. postmortem Sep 01, 2026, 11:47 AM UTC

   ## Customer impact Between August 19, 2026 at 2:33 pm UTC and August 24, 2026 at 11:30 am UTC, a subset of customers could not load UiPath Apps projects authored from Studio Web. Affected customers experienced complete unavailability of Apps projects rather than slowness or degraded performance. The impact was limited to a small set of customers, whose Apps service was hosted in the Japan region. The total customer-impacting duration was approximately 4 days and 21 hours. ## Root cause The root cause was a deployment mismatch between Studio Web and UiPath Apps. On August 19, 2026, Studio Web received a scheduled update in the EU region that included a framework upgrade. The corresponding UiPath Apps update containing the framework upgrade had not yet been deployed to Japan scale unit. An earlier Apps update that was already compatible with the new framework version had been deployed to all regions except Japan, where deployment had been deferred due to unrelated reasons. As a result, the Japan region was still running an older Apps version that was not compatible with the updated Studio Web. ## Detection The issue was reported by a customer through their UiPath account team on August 24, 2026 at 9:36 am UTC. An incident was opened at 10:21 am UTC, and a public status page incident was declared within a minute. Existing automated monitoring did not detect the issue because it validates matched deployment combinations; improving detection for mixed configurations is part of our follow-up plan. ## Response Within minutes of opening the incident, we identified the deployment mismatch as the root cause and decided to accelerate deployment of the corresponding UiPath Apps update to all affected regions, aligning Apps with the Studio Web version already being served to impacted customers. At 10:43 am UTC, we posted a public status update confirming the cause had been identified and that the fix was being deployed. At 10:52 am UTC, deployment was in progress for the remaining regions, with several regions already complete. At 11:30 am UTC, we confirmed the fix had been deployed across all affected regions and marked the incident mitigated. At 11:55 am UTC, after monitoring showed no further impact, the incident was marked resolved. ## Follow up 1. Add automated alerting on production telemetry to detect Apps load failures correlated with the Studio Web version being served. 2. Implement synthetic monitoring that regularly loads an Apps project authored from Studio Web across representative customer configurations and alerts on failure. 3. Adjust release sequencing for tightly coupled Studio Web and Apps changes so that dependent Apps updates are fully deployed to all regions before the newer Studio Web experience reaches customer traffic.

Read the full incident report →

Started Aug 21, 2026, 12:37 PM UTC· resolved Aug 21, 2026, 01:36 PM UTC

1. monitoring Aug 21, 2026, 12:37 PM UTC

   A fix has been implemented for the issue impacting document classification and extraction for Document Understanding in US, and we are currently monitoring the results.

2. resolved Aug 21, 2026, 01:36 PM UTC

   The issue impacting document classification and extraction for Document Understanding in the US region has been resolved. Following a period of monitoring, service is confirmed healthy and operating normally.

3. postmortem Aug 27, 2026, 03:46 AM UTC

   ## Customer impact Between August 21, 2026 at 11:05 am UTC and August 21, 2026 at 12:18 pm UTC, a subset of customers experienced failed Document Understanding operations, including document classification, extraction, and digitization. The estimated duration of the partial outage was 48 minutes. The impact was limited to customers using Document Understanding in the US region. ## Root cause The incident was caused by the Document Understanding storage database failover configuration entering a broken state during a preventive database scale-up operation. The scale-up was initiated after the database approached its storage limit. During the operation, the secondary database could not be scaled, the attempted removal from the failover configuration failed, and the database platform provider had to break the replication link. This left the failover configuration in a temporary unavailable state, causing the storage and runtime services that depend on that database to fail requests. ## Detection The incident was detected through an automated alert for the Document Understanding services, which was acknowledged on August 21, 2026 at 12:10 pm UTC. ## Response Before the customer-impacting incident was declared, the primary database scale-up was completed and support from the database platform provider was engaged for the secondary database issue. After the failover configuration became broken, we explored redirecting the service connection but could not identify a safe, immediate path to do so given the service's current configuration. Service was restored by deleting the unhealthy secondary database and recreating the failover configuration. By August 21, 2026 at 12:37 pm UTC, the fix had been implemented and monitoring was in progress. At 1:36 pm UTC, monitoring confirmed the service was healthy, and the incident was marked resolved. ## Follow up 1. Request a root cause analysis from the database platform provider to determine why the secondary database could not be scaled and why the failover configuration remediation required breaking replication. 2. Update database storage alerting thresholds and routing so alerts are assigned and acted on earlier, including a lower-severity warning at 75% usage and a higher-severity alert at 85% usage.

Read the full incident report →

Started Aug 19, 2026, 03:08 PM UTC· resolved Aug 19, 2026, 04:55 PM UTC

1. investigating Aug 19, 2026, 03:08 PM UTC

   We are investigating an issue that may affect some customers using Claude Sonnet 4.6 in Agents in the US region. Our engineering team is actively working to understand the issue and will share further updates as more information becomes available.

2. investigating Aug 19, 2026, 04:34 PM UTC

   We are investigating an issue that may affect some customers using Claude Sonnet 4.6 in Agents in the US region. Our engineering team is actively working to understand the issue and will share further updates as more information becomes available.

3. monitoring Aug 19, 2026, 04:40 PM UTC

   We have mitigated the issue. Our engineering team is actively morning and will share further updates as more information becomes available.

4. monitoring Aug 19, 2026, 04:42 PM UTC

   We have mitigated the issue. Our engineering team is actively monitoring and will share further updates as more information becomes available.

5. resolved Aug 19, 2026, 04:55 PM UTC

   The issue has been resolved.

6. postmortem Aug 31, 2026, 12:41 PM UTC

   ## Customer Impact Between August 19, 2026 at 1:36 pm UTC and August 19, 2026 at 3:53 pm UTC, a subset of customers received errors when using Claude Sonnet 4.6 in Agents. The impact lasted approximately 2 hours and 17 minutes. The impact was to customers using Agents in the US region. Errors were also observed for Claude Opus 4.6 and Claude Opus 4.5, which are used at lower volume. --- ## Root Cause As part of a planned infrastructure migration, we moved the platform service that routes model requests for Agents onto a new configuration delivery system, region by region. The new configuration source was missing the routing entries for three Claude models — Claude Sonnet 4.6, Claude Opus 4.6, and Claude Opus 4.5. Without those entries, the service could not resolve a valid destination for requests to those models, and rejected them with errors. Other models were unaffected and continued to serve normally throughout. --- ## Detection The issue was detected through customer escalations on August 19, 2026 at 2:55 pm UTC — approximately 1 hour and 19 minutes after the first affected request. Our engineering team scoped the issue to specific Claude models and began investigation. Public status communication began at 3:08 pm UTC. Our alert monitoring is based on aggregate error rates. Although nearly all requests to the three affected models were failing, those models represented a small share of overall traffic in the region, so the aggregate signal did not cross our alerting thresholds and the issue was not raised automatically. This is the detection gap addressed in the follow-up below. --- ## Response At 3:25 pm UTC, the incomplete configuration source was identified as the cause, and a fix was started. At 3:47 pm UTC, deployment of the fix was in progress, and the service was actively monitored as the change rolled out. By 3:59 pm UTC, service logs confirmed the issue was mitigated, and at 4:00 pm UTC the failure rate was confirmed at 0%. The incident was marked mitigated at 4:40 pm UTC, and full resolution was declared at 4:55 pm UTC after continued monitoring and customer confirmation that the service was working as expected. --- ## Follow-Up The infrastructure migration has been completed across all regions and routing configuration now draws from a single source, removing the mismatch that caused this incident so it cannot recur. Automated checks are being introduced to continuously verify every supported model in every region, so an unavailable model is detected and alerted immediately — including in lower-traffic regions.

Read the full incident report →

Started Aug 18, 2026, 05:54 PM UTC· resolved Aug 18, 2026, 11:25 PM UTC

1. investigating Aug 18, 2026, 05:54 PM UTC

   We are investigating reports of an outage impacting failures in expression evaluations related to the HITL task output parameters for Asgentic Orchestratron in community users in Europe. Impact: Users may be unable to complete HITL tasks Next update: Our teams are working to understand the cause and scope and will share updates as available.

2. identified Aug 18, 2026, 07:17 PM UTC

   We have identified the cause for an outage impacting expression evaluations related to the HITL task output parameters for Agentic Orchestration in community users in Europe. Impact: Users will experience failures when they have an expressions using HITL task output parameter. Next update: Our teams are working to understand the cause and scope and will share updates as available.

3. identified Aug 18, 2026, 08:31 PM UTC

   We have identified the cause for an outage impacting expression evaluations related to the HITL task output parameters for Agentic Orchestration in community users in Europe. Impact: Users will experience failures when they have an expressions using HITL task output parameter. Next update: Our teams are working to understand the cause and scope and will share updates as available.

4. identified Aug 18, 2026, 09:45 PM UTC

   We have identified the fix and the resolution is in progress. Next update: Our teams are working on the fix and will share updates as available.

5. monitoring Aug 18, 2026, 10:53 PM UTC

   We have deployed the fix and are monitoring the resolution. Next update: Our teams are monitoring the resolution and will share updates as available.

6. resolved Aug 18, 2026, 11:25 PM UTC

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

7. postmortem Oct 08, 2026, 01:15 AM UTC

   ## Customer impact Between August 18, 2026 at 3:24 pm UTC and 11:25 pm UTC, Agentic Orchestration processes in the subset of users from the Europe region that read fields from a completed human-in-the-loop task could have failed at the expression step. No customer impact was reported: the change reached only the Community ring and the affected feature is rarely used. Paid rings were not affected. No data was lost or changed. ## Root cause The Maestro backend was upgraded to a newer version of the Orchestrator client library to fix an unrelated issue. The new version renamed the fields in the human-in-the-loop task output, and Maestro passed those names straight through to customer expressions, so expressions written against the old names stopped working. This backend change was only in the Community ring. At the same time the process designer was updated to show the new field names in all rings, so outside Community the designer offered names the backend did not return until that change was reverted. ## Detection The issue was detected at 3:24 pm UTC on August 18, 2026 by the team in the Community ring. The incident was declared at 5:28 pm UTC and a public status update was posted at 5:54 pm UTC. ## Response At 5:53 pm UTC the team decided to revert both changes. The designer change was reverted in all rings at 8:24 pm UTC. The backend library upgrade was reverted in the Community ring at 10:49 pm UTC and the incident was marked mitigated at 10:53 pm UTC. At 11:25 pm UTC the fix was verified and the incident was marked resolved. ## Follow up 1. Define the task output contract in Maestro so upstream library changes cannot alter it 2. Add specific automated tests for the task output contract 3. Coordinate designer and backend schema changes in the same release

Read the full incident report →

Started Aug 18, 2026, 12:08 PM UTC· resolved Aug 18, 2026, 07:05 PM UTC

1. identified Aug 18, 2026, 12:08 PM UTC

   We have identified the root cause of an issue in Studio Web where the resource configuration screen for changing resource attributes is not loading. We are deploying a fix.

2. identified Aug 18, 2026, 01:05 PM UTC

   Deployment of the fix is in progress. We will provide further updates as the deployment progresses.

3. identified Aug 18, 2026, 02:06 PM UTC

   The fix has been verified and is being rolled out across all remaining regions. We are monitoring the deployment and recovery. Thanknyou for your patience.

4. identified Aug 18, 2026, 03:06 PM UTC

   The rollout is progressing as expected across the remaining regions. We continue to monitor the deployment. Thank you for your patience.

5. identified Aug 18, 2026, 05:03 PM UTC

   The rollout is progressing as expected across the remaining regions. We continue to monitor the deployment. Thank you for your patience.

6. monitoring Aug 18, 2026, 06:12 PM UTC

   The rollout is progressing as expected across the remaining regions. We continue to monitor the deployment. Thank you for your patience.

7. resolved Aug 18, 2026, 07:05 PM UTC

   The rollout is completed and the issue should be resolved.

8. postmortem Sep 16, 2026, 08:16 AM UTC

   ## Customer impact Between August 14, 2026 and August 18, 2026 at 7:05 pm UTC, the resource configuration screen in Studio Web did not load. Customers could not view or change resource attributes for process resources within the Solutions Management area of Studio Web. Overall, the impact lasted almost a week. Other Studio Web capabilities were not identified as affected. ## Root cause An incorrect resource configuration package version was included in a Studio Web release. Studio Web loads this package to display resource configuration details; because the release referenced the wrong version, the resource configuration screen failed to load. The mismatch was produced by the frontend framework version upgrade for the two services. The fix reverted the package version to the previous working version and required an expedited Studio Web deployment. ## Detection The issue was detected at 11:42 am UTC on August 18, 2026 based on manual smoke testing. The incident was declared customer-impacting at 11:43 am UTC. ## Response At 11:49 am UTC, an expedited fix deployment was started for Studio Web. By 12:08 pm UTC, the root cause had been identified, and a public status update confirmed that a fix was being deployed for the resource configuration screen. At 1:41 pm UTC, the fix was deployed to the first environment. At 1:43 pm UTC, the issue was confirmed resolved in that environment, and deployment continued to remaining regions. By 2:06 pm UTC, the fix had been verified and was being rolled out across all remaining regions. At 6:12 pm UTC, the incident was marked mitigated while deployment monitoring continued. At 7:05 pm UTC, the rollout completed and the incident was marked resolved. ## Follow up 1. Add documentation and protocols for frontend framework version upgrade 2. Add specific automated tests to prevent such regressions on resource configuration

Read the full incident report →

Started Aug 18, 2026, 05:32 AM UTC· resolved Aug 18, 2026, 11:57 AM UTC

1. investigating Aug 18, 2026, 05:32 AM UTC

   We are investigating an issue affecting Community accounts where newly created entities may take approximately one hour to appear in Studio Web. No data is lost, and existing entities are unaffected.

2. investigating Aug 18, 2026, 06:48 AM UTC

   We continue to investigate the issue and are working to identify the root cause and restore normal processing times.

3. investigating Aug 18, 2026, 08:44 AM UTC

   We continue to investigate the issue affecting a subset of tenants in Europe, the United States, and Japan, where newly created entities may take longer than expected to appear in Studio Web. No data is lost, and existing entities are unaffected.

4. identified Aug 18, 2026, 09:37 AM UTC

   We have identified the cause and are working on a resolution for the issue affecting a subset of tenants in Europe, the United States, and Japan. Thank you for your patience.

5. monitoring Aug 18, 2026, 11:19 AM UTC

   The issue has been mitigated, and we expect processing times to return to normal shortly. We are monitoring the recovery closely. Thank you for your patience.

6. resolved Aug 18, 2026, 11:57 AM UTC

   The issue has been resolved, and processing time has returned to normal. Thank you for your patience.

7. postmortem Aug 27, 2026, 03:51 AM UTC

   ## Customer impact Between August 18, 2026 at 5:11 am UTC and August 18, 2026 at 11:57 am UTC, newly created entities in a subset of UiPath Cloud tenants could take longer than expected to appear in Studio Web. At the time of initial assessment, newly created entities were appearing with an approximately one-hour delay. Customers in Europe, US, and Japan were affected. Entity creation itself continued successfully, no data was lost, and existing entities were unaffected. ## Root cause The issue was caused by an unusually high volume of asset-creation requests from one tenant. Those requests generated more events than our backend entity-indexing service could process at the same rate, creating a backlog in the event-processing queue. Because Studio Web relies on this service to display newly created entities, new entities appeared only after the backlog was processed. ## Detection The issue was identified by our engineering team by entity processing latency alert, and an incident was declared at 5:11 am UTC on August 18, 2026. By 5:23 am UTC, analysis confirmed the last processed entity was approximately one hour behind. ## Response At 5:32 am UTC, we posted an initial customer update noting delayed visibility for newly created entities in Studio Web. By 6:07 am UTC, investigation identified unusually high asset-creation traffic from one tenant, and at 7:03 am UTC, we adjusted database resources for the affected service to help processing recover. At 7:59 am UTC, the source of the high request volume had stopped sending requests, and the queue began draining. At 9:59 am UTC, we started a data synchronization process for the affected tenant, and at 10:31 am UTC, we removed the problematic queued events so normal processing could catch up faster. Queue depth decreased from 95,000 items at 8:34 am UTC to 1,000 items at 11:44 am UTC. The incident was marked mitigated at 11:19 am UTC after processing recovered substantially, and resolved at 11:57 am UTC after processing time returned to normal. ## Follow up Re-trigger data synchronization for the affected tenant and monitor ingestion until the tenant's data is confirmed consistent. Improve entity handling in the indexing backend so the backlog will not pile up at this rate.

Read the full incident report →

Started Aug 14, 2026, 09:24 PM UTC· resolved Aug 14, 2026, 11:22 PM UTC

1. identified Aug 14, 2026, 09:24 PM UTC

   We have identified the cause of the degraded performance impacting Orchestrator in US region and are working on mitigation. Impact: Users may experience delayed loads and views on Orchestrator Robot logs. Additional updates will be provided as we move toward resolution.

2. resolved Aug 14, 2026, 11:22 PM UTC

   The issue has been resolved and Orchestrator Robot logs performance has returned to expected levels after degraded performance impacted Robot logs to load in US region. Impact: No ongoing user impact.

3. postmortem Aug 28, 2026, 04:55 PM UTC

   ## Customer impact Between August 14, 2026 at 8:54 pm UTC and August 15, 2026 at 2:09 AM UTC, a subset of customers in the US region experienced significant slowness in the Orchestrator Jobs and Logs pages, and robot logs appeared later than expected in the logs view. Performance had substantially recovered by 11:22 PM UTC on August 14, with full recovery confirmed with affected customers at 2:09 AM UTC on August 15. Automation execution was not affected, jobs continued to be scheduled and to run normally throughout. No log data was lost. Logs continued to be recorded and became visible once the system caught up. Requests did not fail, so no errors were surfaced, pages were slow to load and recent activity appeared missing or delayed. No other region was impacted. ## Root cause Orchestrator stores and retrieves robot logs using a dedicated search and storage system. Routine maintenance on that system causes data to be redistributed internally across the cluster. Our analysis indicates that a redistribution larger than anticipated consumed capacity that would otherwise have served customer requests, slowing both the retrieval of existing logs and the processing of new ones. This accounts for the majority, but not the entirety, of the slowdown observed, and analysis of the remaining contributing factor is continuing. Capacity returned to normal without intervention, at which point log visibility and page performance recovered. ## Detection The issue was surfaced through customer reports of slow Jobs and Logs pages in the US region. ## Response We posted a status update confirming that we were investigating degraded Orchestrator performance in the US region. Our engineering team scoped the impact to the US region and narrowed the slowdown to the log storage and search layer. The degradation stemmed from capacity contention that eased as the redistribution completed, and responders monitored the system through recovery. Page performance and log visibility returned to expected levels over the course of the evening, and recovery was subsequently confirmed with affected customers at 2:09 AM UTC on August 15. ## Follow up 1. We are adding monitoring and alerting on the response times customers experience and on the delay between a robot log being generated and becoming visible, so that degradation of this kind is detected proactively. 2. We are documenting an operational procedure that gives our on-call engineers defined steps to reduce customer impact during this class of degradation. 3. We are changing how routine maintenance on the log storage system is scheduled and paced in the US region so that it does not affect customer-facing performance. 4. We are increasing spare capacity in the log storage system so that internal data movement has room to complete without competing with customer requests.

Read the full incident report →

Started Aug 12, 2026, 03:00 PM UTC· resolved Aug 12, 2026, 06:15 PM UTC

1. resolved Aug 18, 2026, 10:58 AM UTC

   An abnormal usage pattern has caused increased load in IXP Communications Mining's API, impacting API responses across the product with elevated 500 error rates. Limited to a number of customers in the US.

2. postmortem Aug 18, 2026, 09:25 PM UTC

   ## Customer Impact On August 12, 2026, between approximately 15:10 and 18:15 UTC, Communications Mining (IXP) users in the United States region experienced intermittent request failures. The incident was confined to one of the region's deployment units, where users on it saw failures in bursts of five to ten minutes, with up to 5–7% of their requests failing with 5xx errors at peak. Between bursts the service operated normally, retried requests generally succeeded, and no data was lost. ## Root Cause A storm of requests to a rarely used API feature that computes machine-learning predictions on demand coincided with repeated retraining of the requested model. Each retraining invalidated cached predictions, turning each request into a multi-minute computation. The API placed no time limit on how long a request could wait for this computation, so these long-running requests progressively occupied all request-processing capacity, causing unrelated requests to fail. Automatic scaling reached its maximum capacity quickly and could not compensate. ## Detection Automated monitoring detected the failures at 15:15 UTC, about five minutes after impact began, and paged the on-call engineer. The incident was initially attributed only to the client generating the request storm, but client reports and further investigation showed a wider set of users was affected during the failure bursts. ## Response The on-call engineer traced the failures to the unbounded wait in the on-demand prediction path. Service capacity was repeatedly restored by automatic instance replacement while a code fix was developed. The fix is a strict timeout on the contributing request so it fails fast without affecting other requests, and was deployed to the affected region at approximately 18:00 UTC, and resolution was confirmed at 18:15 UTC. ## Follow-Up 1. The strict timeout and load-shedding fix has been made permanent and released to all regions (completed August 13, 2026). 2. Evaluate per-client limits on on-demand prediction computation so that a single client's usage cannot degrade the shared API.

Read the full incident report →

Started Aug 10, 2026, 02:11 PM UTC· resolved Aug 10, 2026, 02:25 PM UTC

1. investigating Aug 10, 2026, 02:11 PM UTC

   We are investigating degraded performance impacting Front-End Services in Document Understanding across GXP East US Region. Impact: Users may notice timeouts when accessing the UI in GXP US. Next update: Additional updates will be provided as more information becomes available.

2. resolved Aug 10, 2026, 02:25 PM UTC

   The issue has been resolved and the performance of the Front-End Service in Document Understanding has returned to expected levels after degraded performance impacted the UI in the GXP East US Region. Impact: No ongoing user impact.

3. postmortem Aug 19, 2026, 06:14 AM UTC

   ## Customer impact Between August 10, 2026 at 13:21 UTC and August 10, 2026 at 14:03 UTC, a subset of customers experienced degraded performance and timeouts when accessing the Document Understanding user interface, which provides the design-time experience, in the Delayed US region. Document processing automations were not affected. ## Root cause During a manual deployment from a pre-existing build of the service behind the Document Understanding user interface to the Delayed US region, our deployment process reassigned the version identifier for the service being deployed. The Document Understanding interface requires that its supporting resources are available under the same version identifier as the deployed service. Because the deployment process changed this identifier, the interface could not locate the required resources, causing it to become inaccessible or time out. ## Detection We became aware of the issue moments after the deployment was finished, through manual verification as part of the manual deployment checklist. An automated alert shortly followed, triggered at 13:28 UTC on August 10, 2026. ## Response After identifying the reason for the failure of the manual deployment, our engineering team started to deploy a corrected update with the required resources available. At the same time, the operations team was engaged to perform a manual rollback of the deployment. The rollback was completed at 14:03 UTC, restoring access to the design-time experience. At 14:11 UTC, we published a public status update indicating degraded performance and possible timeouts in the Document Understanding user interface for the Delayed US region. By 14:15 UTC, the corrected update had completed and the interface was confirmed as deployed with a correct new version and working. At 14:25 UTC, the incident was marked resolved and the public status page was updated to confirm that Document Understanding interface performance had returned to expected levels. ## Follow up 1. We are reducing the time required to restore a previous version of the service, so that recovery from a failed deployment is faster. 2. We are making improvements to the manual deployment process to prevent a future situation, by validating the required resources' existence as a prerequisite.

Read the full incident report →

Started Aug 08, 2026, 11:54 AM UTC· resolved Aug 08, 2026, 04:01 PM UTC

1. identified Aug 08, 2026, 11:54 AM UTC

   We have identified the cause of the outage impacting Uipath Apps is facing outage in Delayed US region and are working on a fix. Impact: Users may continue to be unable to access Uipath Apps and solutions dependent on Uipath Apps. Team is working on service restoration.

2. identified Aug 08, 2026, 01:01 PM UTC

   Team is working on service restoration. We will update the status once mitigation is completed.

3. identified Aug 08, 2026, 02:14 PM UTC

   Team has identified an issue with an underlying resource and is actively working to restore service.

4. identified Aug 08, 2026, 03:30 PM UTC

   Team has made progress to fix underlying resource issue and is actively working to restore service.

5. monitoring Aug 08, 2026, 03:32 PM UTC

   Mitigation has been applied and performance is improving for the issue. We are monitoring closely to ensure stability.

6. resolved Aug 08, 2026, 04:01 PM UTC

   The mitigation has remained stable, and performance has returned to expected levels. We have confirmed service restoration for UiPath Apps in the Delayed US region and are marking this incident as resolved.

7. postmortem Aug 12, 2026, 10:14 AM UTC

   ## Customer impact Between 11:20 am UTC and 2:54 pm UTC on August 8, 2026, a subset of customers in the Delayed US region experienced failures accessing UiPath Apps and solutions that depend on UiPath Apps. Customers may have seen UiPath Apps unavailable or intermittent request failures. The impact lasted approximately 3 hours and 34 minutes. ## Root cause The incident was caused by database connection saturation following scheduled maintenance performed by our database provider. As application services scaled up, they created additional database connections, which caused new connection attempts to fail and resulted in connection reset errors in UiPath Apps. ## Detection Automated alerts detected the issue at 11:24 am UTC on August 8, 2026. Application telemetry showed failures beginning at approximately 11:20 am UTC. ## Response At 11:00 am UTC, scheduled maintenance began automatically. At 11:20 am UTC, requests began failing. At 11:24 am UTC, automated alerts were triggered, and the team began investigating. At 12:24 pm UTC, database capacity was scaled up as a mitigation. At 1:13 pm UTC, application services were restarted to reduce saturated connection usage and refresh database connections. Connection levels remained elevated, and the database automatically scaled at 1:22 pm UTC and at 2:36 pm UTC. Following these mitigation efforts, request failures stopped at 2:54 pm UTC. At 3:33 pm UTC, the mitigation was confirmed to be stable, and performance was improving. Full recovery was confirmed at 4:01 pm UTC after performance returned to expected levels. ## Follow up 1. Obtain and review the database provider's root cause analysis explaining what caused the connection issue following their maintenance activity. 2. Implement an application-side limit on database connection creation to prevent connection saturation. 3. We are reviewing the automatic scaling behavior that amplified connection volume during the incident and address any contributing factors.

Read the full incident report →

Started Aug 06, 2026, 10:00 AM UTC· resolved Aug 06, 2026, 12:57 PM UTC

1. resolved Aug 06, 2026, 09:14 PM UTC

   Between 06-08-2026 10:00 UTC and 06-08-2026 13:00 UTC, some organizations in the US region were unable to complete document ingestion. A small number of search requests in the same region were also slow or timed out. The issue was caused by a capacity constraint affecting ingestion processing in US. Normal performance was restored at 13:00 UTC. We have monitored the affected environments since recovery and confirm the issue is fully mitigated. Ingestion requests that failed during this window were not retried automatically and will need to be re-submitted. No action is required for search.

2. postmortem Aug 13, 2026, 03:12 PM UTC

   ## Customer impact Between August 6, 2026 at 10:00 am UTC and 1:00 pm UTC, some organizations in the US region were unable to complete document ingestion in **UiPath Context Grounding**. A small number of search requests in the same region were also slow or timed out. **Action required:** please re-submit the affected ingestion requests. Ingestion retries a failing request automatically for a limited number of attempts. Once those attempts are exhausted the request is marked failed and is not retried again, so affected documents will not appear in your index until the request is submitted again. Failed requests are listed in the ingestion history for each index. No action is required for search. Those requests were affected only while the issue was ongoing, and subsequent searches completed normally. --- ## Root cause A sudden increase in concurrent document ingestion triggered a high number of simultaneous document validation steps, which created a capacity bottleneck on the underlying infrastructure resource beyond its scaling capacity. Once that resource was saturated, ingestion operations began exceeding their time limits and failing. Automatic retries of the failed operations added further load, which sustained the condition. Search requests served by the same resource were delayed behind the same contention. --- ## Detection Automated alerts were flagged as the condition developed, and an automated infrastructure resource capacity alert triggered at 10:37 am UTC brought it to the team's attention. --- ## Response - **10:03 am UTC** — Automated low severity alerts started coming in. - **10:37 am UTC** — Automated alert for resource capacity issue paged the team. - **12:23 pm UTC** — As a mitigation step the impacted resource's capacity was increased. - **12:57 pm UTC** — Ingestion and search operations stopped failing and response times returned to normal. --- ## Follow-up - **The fix is deployed.** The validation step has been reimplemented to enforce the same limits at a small fraction of the previous cost, so this level of concurrent ingestion now sits well within available capacity. It was released to the affected US region on August 7, ahead of schedule, and reaches all remaining regions by early September. - **We are improving how quickly we detect issues like this.** We are adding monitoring that tracks whether document ingestion is completing successfully for customers, so problems are identified and acted on directly rather than inferred from underlying system alerts. This will be in place across all regions by the end of August.

Read the full incident report →

Started Aug 06, 2026, 07:30 AM UTC· resolved Aug 06, 2026, 07:48 AM UTC

1. resolved Aug 06, 2026, 08:05 AM UTC

   On 06/08/2026 between 7:31 AM - 7:47 AM UTC Uipath Conversational Agent had an outage in Europe region. During this time impacted Customers were unable to access their conversations and create new conversations. The issue is resolved now.

2. postmortem Aug 19, 2026, 01:13 PM UTC

   ## Customer Impact Between 2026-08-06 07:30 UTC and 2026-08-06 07:48 UTC (~18 minutes), some customers in the Europe region experienced intermittent HTTP 500 errors when using their conversational agents. Affected customers may have encountered errors when opening or listing their conversations, or starting new conversations. No data was lost, and the service recovered automatically. ## Root Cause The incident was caused by a temporary disruption in an internal caching component used by the Conversational Agent Service in the Europe region. During the disruption, the caching layer returned unexpected responses, which the service did not handle gracefully. This caused a portion of customer requests to fail instead of completing normally. The caching component stabilized on its own after approximately 18 minutes, and service resumed without manual intervention. ## Detection The issue was detected by automated monitoring, which triggered an alert within minutes of the errors beginning. Additional alerts continued to fire as the condition persisted. ## Response - **07:36 UTC** - Automated alert detected the issue and an incident was created. - **07:48 UTC** - The caching component stabilized and errors stopped. The service recovered without manual intervention. - The engineering team confirmed the recovery and investigated the root cause through application telemetry. ## Follow-Up To prevent similar incidents in the future, we are taking the following steps: - **Improving service resilience** - Updating the service to handle caching disruptions gracefully, so that temporary cache issues do not result in customer-facing errors.

Read the full incident report →

Started Aug 05, 2026, 11:28 PM UTC· resolved Aug 06, 2026, 05:20 AM UTC

1. investigating Aug 05, 2026, 11:28 PM UTC

   We are investigating reports of degraded performance impacting visibility of recent audit log records for AI Trust Layer in the US region. Impact: Users may experience missing or delayed recent records on the AI Trust Layer Audit Log page. Audit log ingestion remains healthy. Our teams are working to identify the cause and will share more details as the investigation progresses.

2. identified Aug 05, 2026, 11:40 PM UTC

   We have identified the cause of degraded performance impacting visibility of recent audit log records for AI Trust Layer in the US region. Impact: Users may experience missing or delayed recent records on the AI Trust Layer Audit Log page. Audit log ingestion remains healthy. Our teams are redeploying the affected service and will continue monitoring recovery. We will share another update as soon as service behavior has stabilized.

3. identified Aug 06, 2026, 12:40 AM UTC

   We have applied a fix and are seeing the affected aggregation jobs run successfully again. Impact: Users may continue to experience delayed visibility of recent records on the AI Trust Layer Audit Log page while processing catches up. Audit log ingestion remains healthy. Our teams are monitoring the backfill process and will share another update once audit log visibility has fully recovered.

4. identified Aug 06, 2026, 01:51 AM UTC

   The fix remains in place and the affected aggregation jobs are continuing to run successfully. Impact: Users may still experience delayed visibility of recent records on the AI Trust Layer Audit Log page while the backfill continues. Audit log ingestion remains healthy. Our teams are continuing to monitor the backfill progress and will share another update once audit log visibility has fully recovered.

5. monitoring Aug 06, 2026, 03:48 AM UTC

   The issue impacting visibility of recent audit log records for AI Trust Layer in the US has been resolved. The affected aggregation jobs are running successfully, and backfill processing has returned to normal. Audit log ingestion remained healthy throughout the incident. We will continue to monitor service health. Thank you for your patience.

6. resolved Aug 06, 2026, 05:20 AM UTC

   All functionality has been restored and the issue is now resolved. Impact: Users should no longer experience issues.

7. postmortem Aug 18, 2026, 09:26 PM UTC

   ## Customer impact Between August 3, 2026 at 3:27 pm UTC and August 6, 2026 at 3:49 am UTC, customers in the US region experienced missing or delayed recent records on the AI Trust Layer Audit Log page. The customer-facing impact lasted approximately 60 hours and 22 minutes. Audit log ingestion remained healthy throughout the incident — records continued to be received and stored. The issue affected only the visibility of recent audit log records while the background processing that prepares records for display was unavailable or recovering. ## Root cause The root cause was a failure in the background processing that prepares recent AI Trust Layer audit log records for display. The processing was failing due to database query timeouts, which prevented newly ingested records from appearing on the Audit Log page. A service restart resolved the immediate failure, after which recovery processing was needed to catch up on the backlog of unprocessed records. ## Detection The audit log view first stopped updating at 3:27 pm UTC on August 3, 2026. The issue was reported and an incident was created on August 5, 2026 at 11:12 pm UTC — approximately 55 hours and 45 minutes after impact began. The incident was declared customer-impacting at 11:13 pm UTC. Investigation confirmed the issue affected visibility of recent AI Trust Layer audit log records in the US region. ## Response At 11:28 pm UTC on August 5, we published an initial status update noting degraded visibility of recent AI Trust Layer audit log records. At 11:40 pm UTC, we confirmed the cause and communicated that the affected service was being restarted. The restart had begun by 11:31 pm UTC. At 12:25 am UTC on August 6, the service restart completed and the background processing was confirmed to be running successfully. At 12:40 am UTC, we updated our status page to confirm the fix was in place and that recovery processing had started, while noting that some customers might still see delayed records until processing caught up. At 3:49 am UTC, recovery processing had returned to normal and recent audit log visibility was fully restored. We continued monitoring and marked the incident resolved at 5:20 am UTC after confirming no further issues. ## Follow up 1. We are evaluating follow-up actions to improve detection speed and prevent recurrence, informed by the processing failure behavior and the recovery observed during this incident. 2. We are reviewing our monitoring and alerting coverage for this service to reduce the time between impact onset and incident detection.

Read the full incident report →

Started Aug 05, 2026, 07:40 AM UTC· resolved Aug 05, 2026, 07:50 AM UTC

1. resolved Aug 06, 2026, 11:04 AM UTC

   On 06/08/2026 between 07:40 AM UTC - 07:50 AM UTC Multiple Uipath services faced an outage due to a downstream service went into bad state. Team was able to fix the issue.

2. postmortem Aug 11, 2026, 02:32 AM UTC

   ## Customer impact Between August 6, 2026 at 7:40 am UTC and August 6, 2026 at 7:50 am UTC, a subset of customers in the Europe region experienced failures when using multiple UiPath services. The impact lasted approximately 10 minutes. Affected services included Action Center, Orchestrator, and other dependent services. Customers may have seen requests fail with server errors during the affected window. ## Root cause An underlying infrastructure update triggered a change in Location Services capacity beyond disruption budget, rendering it in a bad state. Because several UiPath services depend on Location Service, requests through those dependent services returned server errors until the issue was resolved. ## Detection An automated alert fired at 7:45 am UTC on August 6, 2026 and multiple teams were already involved in assessing the situation. ## Response Traffic was automatically diverted to a healthy instance of Location Services and affected services self recovered by 7:50 am UTC on August 6, 2026, ending customer impact. ## Follow up Following this incident, we will improve Location Service resiliency by increasing the headroom available in case of workload shifts and redefine restart strategies.

Read the full incident report →