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.
resolved
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.
postmortem
## 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.
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.
identified
Team is working on service restoration. We will update the status once mitigation is completed.
identified
Team has identified an issue with an underlying resource and is actively working to restore service.
identified
Team has made progress to fix underlying resource issue and is actively working to restore service.
monitoring
Mitigation has been applied and performance is improving for the issue.
We are monitoring closely to ensure stability.
resolved
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.
postmortem
## 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.
๋ฏธ๊ตญ ์ง์ญ ๋ฌธ์ Ingestion
์์ 2026๋ 8์ 6์ผ AM 10:00 UTC ยท 0m
Pending
resolved
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.
postmortem
## 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.