UiPath Status

Resolved: Issue is resolved now.

Monitoring: Issue is mitigated now. we are now monitoring the issue.

Identified: Issue is now resolved in Europe. We are seeing some errors in US and we are continuing to work on the fix.

Identified: We are working to deploy the fix

Identified: We are working to deploy the fix

Identified: We are working to deploy the fix

Identified: We are working to deploy the fix

Identified: We are working to deploy the fix

Identified: Issue resolved in Us region. we are seeing some intermittent failures in Europe region. We are investigating further on this.

Identified: we are seeing some intermittent failures. We are still investigating further on this.

Monitoring: Fix has been applyed we are currently monitoring the service to ensure stability

Monitoring: Fix has been applyed we are currently monitoring the service to ensure stability

Identified: Fix has been applyed we are currently monitoring the service to ensure stability

Identified: The issue causing degraded performance affecting Integration Service in the US and Europe regions has been identified, and mitigation efforts are currently underway.

Identified: Integration Service Customers Facing intermittent failures during connection creation and activities execution in US and Europe regions

Postmortem: ## Customer impact

Between July 7, 2026 (when the defect reached production) and July 9, 2026 at 2:35 pm UTC (when the fix finished rolling out), some attempts to create a new Unstructured and Complex Documents project did not complete normally. The project itself was always created and remained accessible from the project list, but the page showed an error such as "No such source" or "No such project" and returned to the project list instead of opening the new project—interrupting the Autopilot taxonomy generation that runs during project creation. The failure was intermittent, and affected all commercial cloud regions where the feature is available.

Root cause

A recent change introduced a short-lived, in-memory cache of user authorization data in the service, added to improve resilience of authorization checks under load. The cache did not refresh when a user's permissions changed. When a user created a new project, the permissions granted on that new project were not visible to requests served from a stale cache entry (up to 60 seconds old), so immediate follow-up requests failed as if the project did not exist. This caused the error, the redirect back to the project list, and the interruption of Autopilot taxonomy generation.

Detection

The issue was identified through internal testing and user reports on the morning of July 9, 2026, and an incident was declared at 11:02 am UTC. The root cause was identified within minutes of the reports. The public status page was updated at 11:34 am UTC, once the affected feature and regional scope were confirmed. We acknowledge the defect was present in production for approximately two days before detection; improving automated detection of this workflow is a follow-up action.

Response

The engineering team traced the failure to the authorization cache change and rolled back that change across all affected regions. The first region was fixed and verified at 12:52 pm UTC, and all regions were remediated by 1:19 pm UTC. Status page updates were posted at 11:34 am, 12:51 pm, and 2:08 pm UTC while the rollout progressed, and the incident was marked resolved at 2:35 pm UTC after verification.

Follow-up

To prevent a recurrence, we are:

1. Replacing the rolled-back change with a corrected version that refreshes cached authorization data when permissions change, validated end-to-end before release.
2. Adding automated end-to-end checks covering project creation with Autopilot taxonomy generation, so a regression in this workflow is detected within minutes.

Resolved: Issue has been resolved.

Identified: We are deploying fix in progress

Identified: We are working on deploying the fix

Identified: Generating a taxonomy with Autopilot on new IXP Unstructured and Complex Documents projects is currently unavailable across all regions. We have identified the root cause and a fix is being rolled out. We will update this page once the fix is fully deployed and the issue is resolved

Resolved: Degraded performance impacting deploying packages has been fully resolved.

Impact: All affected functionality is operating normally.

Identified: We are currently rolling out the fix to the production environment.

Identified: We are currently deploying the fix in lower environment to validate.

Identified: We have identified the issue. Currently working on deploying the fix.

Investigating: Automation Solutions Service is experiencing connectivity issues while deploying packages containing integration services entities (connectors). We are currently investigating the issue.

Postmortem: ## Customer Impact

On July 8, for about five and a half hours (roughly 12:00 to 17:40 UTC), a subset of Agents customers in the US and EU intermittently received HTTP 500 errors on LLM completion calls. Only calls routed to one affected instance failed, so retries often succeeded. No data was lost and no other functionality was affected.

Root Cause

The failures were caused by SNAT port exhaustion on a single node in one of our shared production clusters. That node reached its fixed limit of outbound ports, which are shared by all pods running on it, so it could no longer open new outbound connections. As a result, the agents calls to the LLM Gateway failed at the network layer and returned 500 to customers.

The exhaustion was driven by the combined outbound connection volume of several services running on that node. We have identified the code that causes this problem, and are implementing a fix.

Response

Detection was delayed because of an independent under-reporting issne in telemetry, so our alerts stayed below paging severity. Once identified, the affected node was drained, which moved the pods onto healthy nodes and stopped the errors immediately. Draining a shared production node is a last-resort action, since it also evicts other teams' workloads from that node, which is why it was applied late rather than early.

Follow-Up

1. Harden the code against SNAT leaks.
2. Create a new alert that would help us identify such issues quickly on the service sde.

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

Monitoring: Mitigation has been applied and performance is improving for LLM Calls in Agents across the US and EU regions. Impact: Users may still experience failed LLM calls, but this should continue to improve. We are monitoring closely to ensure stability.

Investigating: We are investigating reports of degraded performance impacting LLM Calls for Agents in the US and EU regions. Impact: Users may experience errors from LLM calls by Agents. Our teams are working to identify the cause and will share more details as the investigation progresses.

Resolved: Issue is resolved now.

Monitoring: Issue is mitigated now. we are now monitoring the issue.

Identified: Issue is now resolved in Europe. We are seeing some errors in US and we are continuing to work on the fix.

Identified: We are working to deploy the fix

Identified: We are working to deploy the fix

Identified: We are working to deploy the fix

Identified: We are working to deploy the fix

Identified: We are working to deploy the fix

Identified: Issue resolved in Us region. we are seeing some intermittent failures in Europe region. We are investigating further on this.

Identified: we are seeing some intermittent failures. We are still investigating further on this.

Monitoring: Fix has been applyed we are currently monitoring the service to ensure stability

Monitoring: Fix has been applyed we are currently monitoring the service to ensure stability

Identified: Fix has been applyed we are currently monitoring the service to ensure stability

Identified: The issue causing degraded performance affecting Integration Service in the US and Europe regions has been identified, and mitigation efforts are currently underway.

Identified: Integration Service Customers Facing intermittent failures during connection creation and activities execution in US and Europe regions

Postmortem: ## Customer impact

Between July 7, 2026 (when the defect reached production) and July 9, 2026 at 2:35 pm UTC (when the fix finished rolling out), some attempts to create a new Unstructured and Complex Documents project did not complete normally. The project itself was always created and remained accessible from the project list, but the page showed an error such as "No such source" or "No such project" and returned to the project list instead of opening the new project—interrupting the Autopilot taxonomy generation that runs during project creation. The failure was intermittent, and affected all commercial cloud regions where the feature is available.

Root cause

A recent change introduced a short-lived, in-memory cache of user authorization data in the service, added to improve resilience of authorization checks under load. The cache did not refresh when a user's permissions changed. When a user created a new project, the permissions granted on that new project were not visible to requests served from a stale cache entry (up to 60 seconds old), so immediate follow-up requests failed as if the project did not exist. This caused the error, the redirect back to the project list, and the interruption of Autopilot taxonomy generation.

Detection

The issue was identified through internal testing and user reports on the morning of July 9, 2026, and an incident was declared at 11:02 am UTC. The root cause was identified within minutes of the reports. The public status page was updated at 11:34 am UTC, once the affected feature and regional scope were confirmed. We acknowledge the defect was present in production for approximately two days before detection; improving automated detection of this workflow is a follow-up action.

Response

The engineering team traced the failure to the authorization cache change and rolled back that change across all affected regions. The first region was fixed and verified at 12:52 pm UTC, and all regions were remediated by 1:19 pm UTC. Status page updates were posted at 11:34 am, 12:51 pm, and 2:08 pm UTC while the rollout progressed, and the incident was marked resolved at 2:35 pm UTC after verification.

Follow-up

To prevent a recurrence, we are:

1. Replacing the rolled-back change with a corrected version that refreshes cached authorization data when permissions change, validated end-to-end before release.
2. Adding automated end-to-end checks covering project creation with Autopilot taxonomy generation, so a regression in this workflow is detected within minutes.

Resolved: Issue has been resolved.

Identified: We are deploying fix in progress

Identified: We are working on deploying the fix

Identified: Generating a taxonomy with Autopilot on new IXP Unstructured and Complex Documents projects is currently unavailable across all regions. We have identified the root cause and a fix is being rolled out. We will update this page once the fix is fully deployed and the issue is resolved

Resolved: Degraded performance impacting deploying packages has been fully resolved.

Impact: All affected functionality is operating normally.

Identified: We are currently rolling out the fix to the production environment.

Identified: We are currently deploying the fix in lower environment to validate.

Identified: We have identified the issue. Currently working on deploying the fix.

Investigating: Automation Solutions Service is experiencing connectivity issues while deploying packages containing integration services entities (connectors). We are currently investigating the issue.

Postmortem: ## Customer Impact

On July 8, for about five and a half hours (roughly 12:00 to 17:40 UTC), a subset of Agents customers in the US and EU intermittently received HTTP 500 errors on LLM completion calls. Only calls routed to one affected instance failed, so retries often succeeded. No data was lost and no other functionality was affected.

Root Cause

The failures were caused by SNAT port exhaustion on a single node in one of our shared production clusters. That node reached its fixed limit of outbound ports, which are shared by all pods running on it, so it could no longer open new outbound connections. As a result, the agents calls to the LLM Gateway failed at the network layer and returned 500 to customers.

The exhaustion was driven by the combined outbound connection volume of several services running on that node. We have identified the code that causes this problem, and are implementing a fix.

Response

Detection was delayed because of an independent under-reporting issne in telemetry, so our alerts stayed below paging severity. Once identified, the affected node was drained, which moved the pods onto healthy nodes and stopped the errors immediately. Draining a shared production node is a last-resort action, since it also evicts other teams' workloads from that node, which is why it was applied late rather than early.

Follow-Up

1. Harden the code against SNAT leaks.
2. Create a new alert that would help us identify such issues quickly on the service sde.

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

Monitoring: Mitigation has been applied and performance is improving for LLM Calls in Agents across the US and EU regions. Impact: Users may still experience failed LLM calls, but this should continue to improve. We are monitoring closely to ensure stability.

Investigating: We are investigating reports of degraded performance impacting LLM Calls for Agents in the US and EU regions. Impact: Users may experience errors from LLM calls by Agents. Our teams are working to identify the cause and will share more details as the investigation progresses.

Postmortem: ## Customer impact

Between July 7, 2026 (when the defect reached production) and July 9, 2026 at 2:35 pm UTC (when the fix finished rolling out), some attempts to create a new Unstructured and Complex Documents project did not complete normally. The project itself was always created and remained accessible from the project list, but the page showed an error such as "No such source" or "No such project" and returned to the project list instead of opening the new project—interrupting the Autopilot taxonomy generation that runs during project creation. The failure was intermittent, and affected all commercial cloud regions where the feature is available.

Root cause

A recent change introduced a short-lived, in-memory cache of user authorization data in the service, added to improve resilience of authorization checks under load. The cache did not refresh when a user's permissions changed. When a user created a new project, the permissions granted on that new project were not visible to requests served from a stale cache entry (up to 60 seconds old), so immediate follow-up requests failed as if the project did not exist. This caused the error, the redirect back to the project list, and the interruption of Autopilot taxonomy generation.

Detection

The issue was identified through internal testing and user reports on the morning of July 9, 2026, and an incident was declared at 11:02 am UTC. The root cause was identified within minutes of the reports. The public status page was updated at 11:34 am UTC, once the affected feature and regional scope were confirmed. We acknowledge the defect was present in production for approximately two days before detection; improving automated detection of this workflow is a follow-up action.

Response

The engineering team traced the failure to the authorization cache change and rolled back that change across all affected regions. The first region was fixed and verified at 12:52 pm UTC, and all regions were remediated by 1:19 pm UTC. Status page updates were posted at 11:34 am, 12:51 pm, and 2:08 pm UTC while the rollout progressed, and the incident was marked resolved at 2:35 pm UTC after verification.

Follow-up

To prevent a recurrence, we are:

1. Replacing the rolled-back change with a corrected version that refreshes cached authorization data when permissions change, validated end-to-end before release.
2. Adding automated end-to-end checks covering project creation with Autopilot taxonomy generation, so a regression in this workflow is detected within minutes.

Resolved: Issue has been resolved.

Identified: We are deploying fix in progress

Identified: We are working on deploying the fix

Identified: Generating a taxonomy with Autopilot on new IXP Unstructured and Complex Documents projects is currently unavailable across all regions. We have identified the root cause and a fix is being rolled out. We will update this page once the fix is fully deployed and the issue is resolved

Postmortem: ## Customer impact

Between July 7, 2026 (when the defect reached production) and July 9, 2026 at 2:35 pm UTC (when the fix finished rolling out), some attempts to create a new Unstructured and Complex Documents project did not complete normally. The project itself was always created and remained accessible from the project list, but the page showed an error such as "No such source" or "No such project" and returned to the project list instead of opening the new project—interrupting the Autopilot taxonomy generation that runs during project creation. The failure was intermittent, and affected all commercial cloud regions where the feature is available.

Root cause

A recent change introduced a short-lived, in-memory cache of user authorization data in the service, added to improve resilience of authorization checks under load. The cache did not refresh when a user's permissions changed. When a user created a new project, the permissions granted on that new project were not visible to requests served from a stale cache entry (up to 60 seconds old), so immediate follow-up requests failed as if the project did not exist. This caused the error, the redirect back to the project list, and the interruption of Autopilot taxonomy generation.

Detection

The issue was identified through internal testing and user reports on the morning of July 9, 2026, and an incident was declared at 11:02 am UTC. The root cause was identified within minutes of the reports. The public status page was updated at 11:34 am UTC, once the affected feature and regional scope were confirmed. We acknowledge the defect was present in production for approximately two days before detection; improving automated detection of this workflow is a follow-up action.

Response

The engineering team traced the failure to the authorization cache change and rolled back that change across all affected regions. The first region was fixed and verified at 12:52 pm UTC, and all regions were remediated by 1:19 pm UTC. Status page updates were posted at 11:34 am, 12:51 pm, and 2:08 pm UTC while the rollout progressed, and the incident was marked resolved at 2:35 pm UTC after verification.

Follow-up

To prevent a recurrence, we are:

1. Replacing the rolled-back change with a corrected version that refreshes cached authorization data when permissions change, validated end-to-end before release.
2. Adding automated end-to-end checks covering project creation with Autopilot taxonomy generation, so a regression in this workflow is detected within minutes.

Resolved: Issue has been resolved.

Identified: We are deploying fix in progress

Identified: We are working on deploying the fix

Identified: Generating a taxonomy with Autopilot on new IXP Unstructured and Complex Documents projects is currently unavailable across all regions. We have identified the root cause and a fix is being rolled out. We will update this page once the fix is fully deployed and the issue is resolved