UiPath Status

Postmortem: ## Customer impact

On , between approximately 15:45 UTC and 18:45 UTC, customers hosted in the Europe, Australia and Japan regions were unable to see recent robot logs in Orchestrator. Logs written during the impact window did not appear in the Jobs and Logs views or through the Robot Logs API, and logs older than approximately 03:00 UTC that day were available only intermittently. The impact window differed per region:

• Australia: approximately 15:45 UTC to 18:35 UTC
• Europe: approximately 16:35 UTC to 18:00 UTC
• Japan: approximately 16:45 UTC to 18:30 UTC

Job execution, queues, triggers and all other Orchestrator functionality were not affected. No robot logs were lost. Logs produced during the impact window continued to be collected and became visible again once the issue was mitigated.

Root cause

We were performing a scheduled upgrade of the Elasticsearch service that stores Orchestrator robot logs. The upgrade uses a blue/green approach: a new cluster is created alongside the existing one, the data is restored into it from a backup, the pipeline that ingests new logs is started on it, and only then is traffic switched over.

In the affected regions, the traffic switch was approved by the engineer running the upgrade before the data restore and the ingestion catch-up had completed, which is a deviation from our upgrade procedure. This was a human error. As a result, Orchestrator was reading robot logs from a cluster that did not yet contain recent data, while new logs continued to be collected but were not yet indexed on the cluster serving requests. The error was not caught because our deployment tooling relies on the operator to verify data completeness and does not enforce the order between the data restore and the traffic switch.

Detection

Our synthetic monitoring, which continuously runs test jobs and verifies that their logs are returned, detected missing logs in the affected regions and raised alerts. Our engineering team correlated the alerts with the in-progress upgrade, declared an incident and published a status page notification.

Response

Our engineering team reverted the traffic to the previous Elasticsearch clusters in all three regions, which immediately restored access to all robot logs, including those produced during the impact window. We confirmed recovery through synthetic monitoring in every affected region and continued monitoring before marking the incident resolved at approximately 18:45 UTC.

The upgrade of the new clusters continues in the background. Traffic will be moved to them only after the data restore is complete and ingestion is confirmed to be up to date.

Follow up

To prevent this from happening again, we are:

• Changing the deployment pipeline so that the traffic switch cannot run until the data restore and log ingestion on the new cluster are verified as complete.
• Adding an automated rollback step to the pipeline, so traffic can be returned to the previous cluster within minutes if a problem is detected after a switch.

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

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

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

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

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

Postmortem: ## Customer impact

On October 1, 2026, from 10:50 to 19:50 UTC, some Studio Web users in Europe couldn't debug agents that call Orchestrator processes (RPA, agents, etc.) or Action Apps from the same solution. The call failed with a "not found" error. Published agents and production jobs were not affected.

Root cause

A Studio Web update changed how solution resources are located during debugging. It was missing a setting that keeps the previous behavior, so debug runs looked for the solution's resources in the user's personal workspace instead of the debug folder.

Detection

Automated end-to-end tests alerted our engineers at 16:43 UTC. The end-to-end testing suite runs once every 2 hours and alerting only happens after 3 consecutive test failures. The issue was also reported from a customer environment.

Response

After identifying the root cause, a rollback was started at 18:00 UTC and was fully in effect at 19:50 UTC. This duration included a deployment failure that had to be retried, which took 50 minutes. A corrected version that includes the setting was deployed on October 2 at 13:00 UTC.

Follow up

1. The setting is now part of the main code line, so future releases include it.
2. We're improving the alerts and the end-to-end testing suite to catch regressions earlier.

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

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

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

Postmortem: ## Customer impact

On October 1, 2026, from 14:31 to 19:40 UTC, agents configured with some large language models, including Gemini 3.1 Pro Preview and GPT-4o (2024-05-13), failed to start in all regions, with an error saying the model is not available. The same models were missing from the model list while designing agents. Agents using other models were not affected.

Root cause

A feature flag was flipped, causing Agents service to begin sending an operation code to model discovery requests. This caused the list of models served to be that specific operation’s as opposed to the base agents model list. The per operation model list was initially seeded from the Bring Your Own Model (BYOM) configuration of overridable models, which crucially for agents did not have parity with the full list of supported models in Agents service. Internal audit showed this was an error and not an intentional gap.

Over time this gap was never addressed and after the flag switch, agents already configured with any of the affected models would fail because of their absence from the returned list.

Detection

A customer reported the issue, and it was escalated to our engineers at 16:44 UTC. Our monitoring did not alert, because this error usually points to organization or agent level configuration issues.

Response

Engineers traced the failures to the configuration change and reverted it at 19:01 UTC. The revert took effect over the following minutes, and the last failure occurred at 19:40 UTC.

Follow up

1. The model lists will be aligned before this change is made again.
2. We're changing how this error is classified so a platform-wide spike alerts our engineers.

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

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

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

Postmortem: ## Customer impact

Between approximately 11:00 UTC and 13:40 UTC on October 1, 2026, customers in the US region observed slower Orchestrator response times and intermittent timeouts. Robots took longer to start jobs, process queue items and read assets, and some of these requests failed.

Other UiPath services that rely on Orchestrator were also affected while Orchestrator was degraded, and may have seen slower responses or errors.

Root cause

An Orchestrator fix deployment included a change to how computing capacity is reserved and scaled for our services. The change was meant to use our infrastructure more efficiently, but it lowered the processing capacity available to Orchestrator. During busy periods our automatic scaling did not add capacity as expected, so the service could not keep up with demand.

Detection

Our internal monitoring detected the slowdown after the update. Our first plan was to release a corrected update through our standard release process, which takes several hours. When customer reports began coming in, we opened an incident and moved to a faster fix.

Response

Our engineering team applied the previous capacity settings directly to the affected services, without waiting for the corrected update. Response times returned to normal at approximately 13:40 UTC, and we continued monitoring to confirm the service was stable.

Follow up

To prevent this from happening again, we are:

• Permanently restoring the previous capacity settings, and reviewing any future capacity changes against production-level load before rollout.
• Improving how we assess customer impact during degradations, so they are escalated to an incident earlier.
• Making it faster to roll back capacity and configuration changes when they affect customers.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Postmortem: ## Customer impact

Between approximately 11:00 UTC and 13:40 UTC on October 1, 2026, customers in the US region observed slower Orchestrator response times and intermittent timeouts. Robots took longer to start jobs, process queue items and read assets, and some of these requests failed.

Other UiPath services that rely on Orchestrator were also affected while Orchestrator was degraded, and may have seen slower responses or errors.

Root cause

An Orchestrator fix deployment included a change to how computing capacity is reserved and scaled for our services. The change was meant to use our infrastructure more efficiently, but it lowered the processing capacity available to Orchestrator. During busy periods our automatic scaling did not add capacity as expected, so the service could not keep up with demand.

Detection

Our internal monitoring detected the slowdown after the update. Our first plan was to release a corrected update through our standard release process, which takes several hours. When customer reports began coming in, we opened an incident and moved to a faster fix.

Response

Our engineering team applied the previous capacity settings directly to the affected services, without waiting for the corrected update. Response times returned to normal at approximately 13:40 UTC, and we continued monitoring to confirm the service was stable.

Follow up

To prevent this from happening again, we are:

• Permanently restoring the previous capacity settings, and reviewing any future capacity changes against production-level load before rollout.
• Improving how we assess customer impact during degradations, so they are escalated to an incident earlier.
• Making it faster to roll back capacity and configuration changes when they affect customers.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Postmortem: ## Customer impact

On October 1, 2026, from 14:31 to 19:40 UTC, agents configured with some large language models, including Gemini 3.1 Pro Preview and GPT-4o (2024-05-13), failed to start in all regions, with an error saying the model is not available. The same models were missing from the model list while designing agents. Agents using other models were not affected.

Root cause

A feature flag was flipped, causing Agents service to begin sending an operation code to model discovery requests. This caused the list of models served to be that specific operation’s as opposed to the base agents model list. The per operation model list was initially seeded from the Bring Your Own Model (BYOM) configuration of overridable models, which crucially for agents did not have parity with the full list of supported models in Agents service. Internal audit showed this was an error and not an intentional gap.

Over time this gap was never addressed and after the flag switch, agents already configured with any of the affected models would fail because of their absence from the returned list.

Detection

A customer reported the issue, and it was escalated to our engineers at 16:44 UTC. Our monitoring did not alert, because this error usually points to organization or agent level configuration issues.

Response

Engineers traced the failures to the configuration change and reverted it at 19:01 UTC. The revert took effect over the following minutes, and the last failure occurred at 19:40 UTC.

Follow up

1. The model lists will be aligned before this change is made again.
2. We're changing how this error is classified so a platform-wide spike alerts our engineers.

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

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

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

Postmortem: ## Customer impact

On , between approximately 15:45 UTC and 18:45 UTC, customers hosted in the Europe, Australia and Japan regions were unable to see recent robot logs in Orchestrator. Logs written during the impact window did not appear in the Jobs and Logs views or through the Robot Logs API, and logs older than approximately 03:00 UTC that day were available only intermittently. The impact window differed per region:

• Australia: approximately 15:45 UTC to 18:35 UTC
• Europe: approximately 16:35 UTC to 18:00 UTC
• Japan: approximately 16:45 UTC to 18:30 UTC

Job execution, queues, triggers and all other Orchestrator functionality were not affected. No robot logs were lost. Logs produced during the impact window continued to be collected and became visible again once the issue was mitigated.

Root cause

We were performing a scheduled upgrade of the Elasticsearch service that stores Orchestrator robot logs. The upgrade uses a blue/green approach: a new cluster is created alongside the existing one, the data is restored into it from a backup, the pipeline that ingests new logs is started on it, and only then is traffic switched over.

In the affected regions, the traffic switch was approved by the engineer running the upgrade before the data restore and the ingestion catch-up had completed, which is a deviation from our upgrade procedure. This was a human error. As a result, Orchestrator was reading robot logs from a cluster that did not yet contain recent data, while new logs continued to be collected but were not yet indexed on the cluster serving requests. The error was not caught because our deployment tooling relies on the operator to verify data completeness and does not enforce the order between the data restore and the traffic switch.

Detection

Our synthetic monitoring, which continuously runs test jobs and verifies that their logs are returned, detected missing logs in the affected regions and raised alerts. Our engineering team correlated the alerts with the in-progress upgrade, declared an incident and published a status page notification.

Response

Our engineering team reverted the traffic to the previous Elasticsearch clusters in all three regions, which immediately restored access to all robot logs, including those produced during the impact window. We confirmed recovery through synthetic monitoring in every affected region and continued monitoring before marking the incident resolved at approximately 18:45 UTC.

The upgrade of the new clusters continues in the background. Traffic will be moved to them only after the data restore is complete and ingestion is confirmed to be up to date.

Follow up

To prevent this from happening again, we are:

• Changing the deployment pipeline so that the traffic switch cannot run until the data restore and log ingestion on the new cluster are verified as complete.
• Adding an automated rollback step to the pipeline, so traffic can be returned to the previous cluster within minutes if a problem is detected after a switch.

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

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

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

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

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

Postmortem: ## Customer impact

On October 1, 2026, from 14:31 to 19:40 UTC, agents configured with some large language models, including Gemini 3.1 Pro Preview and GPT-4o (2024-05-13), failed to start in all regions, with an error saying the model is not available. The same models were missing from the model list while designing agents. Agents using other models were not affected.

Root cause

A feature flag was flipped, causing Agents service to begin sending an operation code to model discovery requests. This caused the list of models served to be that specific operation’s as opposed to the base agents model list. The per operation model list was initially seeded from the Bring Your Own Model (BYOM) configuration of overridable models, which crucially for agents did not have parity with the full list of supported models in Agents service. Internal audit showed this was an error and not an intentional gap.

Over time this gap was never addressed and after the flag switch, agents already configured with any of the affected models would fail because of their absence from the returned list.

Detection

A customer reported the issue, and it was escalated to our engineers at 16:44 UTC. Our monitoring did not alert, because this error usually points to organization or agent level configuration issues.

Response

Engineers traced the failures to the configuration change and reverted it at 19:01 UTC. The revert took effect over the following minutes, and the last failure occurred at 19:40 UTC.

Follow up

1. The model lists will be aligned before this change is made again.
2. We're changing how this error is classified so a platform-wide spike alerts our engineers.

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

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

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

Postmortem: ## Customer impact

On October 1, 2026, from 14:31 to 19:40 UTC, agents configured with some large language models, including Gemini 3.1 Pro Preview and GPT-4o (2024-05-13), failed to start in all regions, with an error saying the model is not available. The same models were missing from the model list while designing agents. Agents using other models were not affected.

Root cause

A feature flag was flipped, causing Agents service to begin sending an operation code to model discovery requests. This caused the list of models served to be that specific operation’s as opposed to the base agents model list. The per operation model list was initially seeded from the Bring Your Own Model (BYOM) configuration of overridable models, which crucially for agents did not have parity with the full list of supported models in Agents service. Internal audit showed this was an error and not an intentional gap.

Over time this gap was never addressed and after the flag switch, agents already configured with any of the affected models would fail because of their absence from the returned list.

Detection

A customer reported the issue, and it was escalated to our engineers at 16:44 UTC. Our monitoring did not alert, because this error usually points to organization or agent level configuration issues.

Response

Engineers traced the failures to the configuration change and reverted it at 19:01 UTC. The revert took effect over the following minutes, and the last failure occurred at 19:40 UTC.

Follow up

1. The model lists will be aligned before this change is made again.
2. We're changing how this error is classified so a platform-wide spike alerts our engineers.

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

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

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