Uipath status

Official status checked

All systems operational

Official incident resolved

Multiple Region - Insights & Automation Ops Service Down — The issue has been resolved, and all services are now operating normally.

Official incident resolved

Gemini-2.5-Flash not working in Australia — ## Customer impact Between October 22, 2026 at 10:24 am UTC and October 22, 2026 at 6:04 pm UTC, document processing requests that used Gemini 2.5 Flash in the Australia region failed with capacity errors. The impact lasted approximately 7 hours and 40 minutes. A subset of customers using document extraction workflows in that region were affected. During a temporary in-region fallback attempt, some extraction requests recovered briefly, but word-level attribution and generated page text were degraded until the fallback also began failing. ## Root cause The root cause was a provider-side regional network disruption during concurrent maintenance. This caused severe bandwidth throttling in the provider's model-serving environment, which prevented the backend systems from loading the model data needed to serve Gemini 2.5 Flash and Gemini 3.5 Flash requests reliably in the affected region. ## Detection The issue was detected through automated alerting that identified rate-limiting errors on Gemini 2.5 Flash in the Australia region. Our engineering team confirmed through telemetry that affected requests were failing consistently and began coordinating a response. ## Response At 1:40 pm UTC, we routed affected Gemini 2.5 Flash traffic to Gemini 3.5 Flash within the same region to preserve data residency. Initial telemetry showed no capacity errors after that change, but by 2:10 pm UTC, Gemini 3.5 Flash was also returning capacity errors, so the fallback was no longer viable. At 2:05 pm UTC, we adjusted related document processing paths so attribution and page-text generation would use the same in-region fallback; that adjustment completed at approximately 2:09 pm UTC. After the fallback also failed, we reverted the routing change, and by 4:28 pm UTC traffic was back on the expected Gemini 2.5 Flash path. At 5:38 pm UTC, telemetry showed improving Gemini 2.5 Flash success rates. From 6:04 pm UTC onward, no further capacity errors were observed, and subsequent requests succeeded. ## Follow up 1. Complete the reserved model capacity assessment for the affected region using the observed traffic patterns 2. Evaluate retry and backoff behavior in document processing clients to reduce retry amplification during provider-side capacity failures.

Official incident resolved

Multiple Regions - Multiple Services Failing Due to Certificate Expiry — ## Customer Impact Between 13:37 and 14:40 UTC on October 13, 2026, customers across multiple regions were unable to use IXP Unstructured Documents, IXP Communications Mining and Document Understanding. Computer Vision and Autopilot for Developers features that depend on the same machine learning services also failed. Affected customers saw requests fail with "500 Internal Server Error" responses or time out, IXP projects that would not open, and Computer Vision activities failing in running automations. Service was disrupted for approximately 1 hour. No customer data was lost. ## Root Cause The incident was caused by an expired security certificate used to establish secure connections to these services. The certificate is renewed by an automated process. That process was no longer executing successfully and the failures did not raise an alert, so the certificate was not replaced before it expired. Secure connections to the affected services were rejected from 13:37 UTC. ## Detection Automated monitoring began alerting on errors and missing traffic at 13:40 UTC, and the incident was declared at 13:54 UTC. The expired certificate was identified at 14:00 UTC, and the first status page update was posted at 14:03 UTC. No alert warned that the certificate was approaching expiry, and the repeated failures of the automated renewal were not reported to the owning team, so the problem was only detected once customers were affected. ## Response At 14:06 UTC the team confirmed that the certificate had expired because the automated renewal had been failing. At 14:18 UTC a new credential was issued for the renewal process. The renewal was started manually at 14:19 UTC and completed at 14:33 UTC, and by 14:37 UTC every customer-facing endpoint had been verified to serve the renewed certificate. Traffic returned to normal levels by approximately 14:40 UTC. After a period of monitoring, the incident was resolved at 15:19 UTC. ## Follow-Up To help prevent similar incidents in the future, we are making the following improvements: - Alert well in advance of any of these certificates approaching expiry. - Notify the owning team whenever the automated renewal fails. - Add checks that alert as soon as secure connections to these services fail. - Strengthen ownership of the certificate renewal process and the credentials it relies on.