Störungsverlauf von Uipath

1. 3. September 2026 um 15:34 UTCinvestigating

   Wir investieren derzeit das Problem

2. 3. September 2026 um 15:39 UTCidentified

   Das Problem wurde identifiziert und die geeigneten Minderungsmaßnahmen wurden umgesetzt, um es zu beheben.

3. 3. September 2026 um 15:47 UTCmonitoring

   Das Problem wurde erfolgreich behoben und der Service wurde vollständig wiederhergestellt. Der Dienst funktioniert derzeit normal.

4. 3. September 2026 um 16:17 UTCresolved

   Das Problem wurde erfolgreich behoben und der Service wurde vollständig wiederhergestellt. Der Dienst funktioniert derzeit normal.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 4. September 2026 um 17:48 UTCresolved

   Im Insights-Dashboard in Looker wurde ein Problem festgestellt, das verhinderte, dass die neuesten Maestro-Läufe im Dashboard angezeigt wurden Betroffene Regionen: USA, SEA, IND, CA, AUE, JP, UK Ereigniszeitleiste Begonnen: 2. September 2026 um 20:00:00 UTC Entschlossen: 4. September 2026 um 16:30:00 UTC Das Problem wurde derzeit behoben, und das Insights-Dashboard zeigt die neuesten Maestro-Laufdaten an.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 1. September 2026 um 13:49 UTCinvestigating

   Wir untersuchen Berichte über verschlechterte Leistung, die sich auf die Digitalisierung und Extraktion für Document Understanding und IXP in den USA auswirken. Auswirkungen: Benutzer können Langsamkeit und fehlgeschlagene Document Understanding-Runtime-Operationen erleben. Unsere Teams arbeiten daran, die Ursache zu identifizieren und werden im Laufe der Untersuchung weitere Details mitteilen.

2. 1. September 2026 um 14:07 UTCmonitoring

   Wir haben das Problem identifiziert und eine Abschwächung vorgenommen. Die Dienste werden wieder in einen gesunden Zustand versetzt und wir überwachen die Dienste.

3. 1. September 2026 um 15:06 UTCresolved

   Dieses Problem wurde vollständig gelöst und die Dienste sind jetzt stabil. Wir werden bald weitere Details des Vorfalls auf der Statusseite veröffentlichen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 31. August 2026 um 16:55 UTCinvestigating

   Wir untersuchen derzeit das Problem.

2. 31. August 2026 um 17:07 UTCidentified

   Wir haben das Problem identifiziert und den notwendigen Fix implementiert

3. 31. August 2026 um 18:24 UTCmonitoring

   Das Problem wurde gemildert und der Dienst ist derzeit in Betrieb. Wir werden den Servicezustand weiterhin genau beobachten und bei Bedarf weitere Maßnahmen ergreifen.

4. 31. August 2026 um 19:39 UTCresolved

   Das Problem wurde gemildert und der Dienst ist derzeit in Betrieb. Wir werden den Servicezustand weiterhin genau beobachten und bei Bedarf weitere Maßnahmen ergreifen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 28. August 2026 um 15:41 UTCidentified

   Das Problem wurde identifiziert und das Team arbeitet aktiv an der Bereitstellung eines Fixes. Wir erwarten, dass der Einsatz in den kommenden Stunden beginnen wird.

2. 28. August 2026 um 17:27 UTCmonitoring

   Wir haben die Ursache für die verschlechterte Leistung identifiziert und sind dabei, in den kommenden Stunden einen Fix bereitzustellen. Es betrifft verknüpfte Abfragen, bei denen der Benutzer keinen Zugriff auf den ursprünglichen Ordner hat. Die API-Oberfläche ist nicht betroffen. Export via CSV kann als Workaround genutzt werden. Zusätzliche Updates werden zur Verfügung gestellt, während wir uns in Richtung Auflösung bewegen.

3. 28. August 2026 um 17:39 UTCidentified

   Wir haben die Ursache für die verschlechterte Leistung identifiziert und sind dabei, in den kommenden Stunden einen Fix bereitzustellen. Es betrifft verknüpfte Abfragen, bei denen der Benutzer keinen Zugriff auf den ursprünglichen Ordner hat. Die API-Oberfläche ist nicht betroffen. Export via CSV kann als Workaround genutzt werden. Zusätzliche Updates werden zur Verfügung gestellt, während wir uns in Richtung Auflösung bewegen.

4. 28. August 2026 um 20:00 UTCidentified

   Der Fix wird derzeit angewendet. Wir werden in Kürze ein weiteres Update bereitstellen, sobald der Einsatz in allen betroffenen Regionen abgeschlossen ist.

5. 28. August 2026 um 22:57 UTCresolved

   Der Fix wurde erfolgreich in allen Regionen eingesetzt und wir haben bestätigt, dass das Problem behoben ist. Der Service funktioniert wie erwartet.

6. 3. September 2026 um 08:49 UTCpostmortem

   ## Customer Impact Zwischen dem 28. August 2026 um 15:23 Uhr UTC und dem 28. August 2026 um 22:57 Uhr UTC gab es bei einer Teilmenge von Kunden Fehler beim Öffnen von Warteschlangen-Detail-Panels in Orchestrator. Der betroffene Pfad gab eine 404-Seite für verknüpfte Warteschlangen zurück, wenn der Benutzer KEINEN Zugriff auf den ursprünglichen Ordner hatte, in dem die Elemente erstellt wurden. Die Auswirkungen betrafen nur Orchestrator-Benutzeroberflächeninteraktionen und erstreckten sich über alle Regionen, in denen die betroffene Softwareversion ausgeführt wird. Orchestrator Application Programming Interface Access war nicht betroffen und der Export von Warteschlangendaten in CSV war als Workaround verfügbar. Die Gesamtdauer betrug ca. 7 Stunden. ## Wurzelursache Der Vorfall wurde durch eine Regression in der Orchestrator-Benutzeroberfläche für verknüpfte Warteschlangen verursacht, auf die aus anderen Ordnern zugegriffen wurde. Die Regression hat den Fluss der verknüpften Warteschlangendetails nicht korrekt behandelt, wenn der anfordernde Benutzer keinen Zugriff auf den ursprünglichen Ordner hatte, was dazu führte, dass das Warteschlangenelementdetailfeld auf eine 404-Seite weitergeleitet wurde, anstatt die erwarteten Informationen anzuzeigen. Detektion Das Problem wurde durch einen automatisierten Vorfallsalarm für das Orchestrator-Frontend am 28. August 2026 um 15:23 Uhr UTC erkannt. ## Antwort Um 15.31 Uhr UTC am 28. August 2026 beschrieb unser Ingenieurteam das Problem als Kunden, die aufgrund einer Regression nicht auf die Details der Warteschlangen zugreifen konnten. Um 15:41 Uhr UTC bestätigte ein öffentliches Statusupdate, dass die Ursache identifiziert wurde, dass ein Fix bereitgestellt wurde und dass der Zugriff auf die Anwendungsprogrammierschnittstelle nicht betroffen war. Um 17:27 Uhr UTC wurde der Umfang auf verknüpfte Warteschlangen beschränkt, in denen der Benutzer keinen Zugriff auf den ursprünglichen Ordner hatte. Um 17:29 Uhr UTC stellte das Team fest, dass der anfängliche Fix das betroffene Szenario nicht vollständig ansprach, und es wurde ein korrigierter Fix entwickelt. Um 17:30 Uhr UTC wurde das betroffene Szenario reproduziert und der korrigierte Fix lokal validiert. Um 17:39 Uhr UTC dokumentierte ein Statusseiten-Update den CSV-Export als Workaround. Der Einsatz des korrigierten Fixes wurde in den betroffenen Regionen fortgesetzt. Um 22:50 Uhr UTC wurde bestätigt, dass der Fix überall eingesetzt wurde. Um 22:57 Uhr UTC wurde der Vorfall als behoben markiert und die Statusseite wurde aktualisiert, um zu bestätigen, dass der Dienst wie erwartet funktionierte. ## Follow-up Formale Folgemaßnahmen werden durch den bei der Auflösung eingeleiteten Überprüfungsprozess nach dem Vorfall verfolgt. ## Aktionspunkte - Erweiterung unserer automatisierten Testfälle um dieses Szenario und andere ähnliche Szenarien im Zusammenhang mit verknüpften Objekten oder Ordnerkreuzszenarien. Sicherstellen, dass wir Änderungen über ein Flag sicher ausschalten können, um die Reaktionszeit zu beschleunigen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 27. August 2026 um 17:16 UTCinvestigating

   Wir untersuchen Berichte über fehlende Roboterprotokolle in der US-Region. Unsere Teams arbeiten daran, die Ursache zu identifizieren und werden im Laufe der Untersuchung weitere Details mitteilen.

2. 27. August 2026 um 18:53 UTCidentified

   Wir stellten fest, dass die Aufnahme von Roboterprotokollen verzögert wurde. Roboterprotokolle holen live-daten auf und wir überwachen die wiederherstellung.

3. 27. August 2026 um 20:31 UTCmonitoring

   Die Protokolle füllen nun wie erwartet in Echtzeit und wir werden die Anwendung weiterhin überwachen.

4. 27. August 2026 um 21:57 UTCresolved

   Das Problem wurde behoben und die Protokolle füllen sich wie erwartet.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 25. August 2026 um 09:41 UTCidentified

   Wir haben ein Problem identifiziert, das sich auf die Lösungsbereitstellung im Studio Web in der Region Japan auswirkt und bei dem Lösungsbereitstellungen möglicherweise fehlschlagen. Ein Fix wurde vorbereitet und wird in Kürze ausgerollt. Wir werden weitere Updates bereitstellen, sobald weitere Informationen verfügbar sind.

2. 25. August 2026 um 09:47 UTCmonitoring

   Der Fix wurde erfolgreich in der Region Japan eingesetzt und das Problem wurde gemildert. Wir beobachten den Service genau, um sicherzustellen, dass die Lösungsbereitstellung weiterhin wie erwartet funktioniert und bei Bedarf weitere Updates bereitstellen wird.

3. 25. August 2026 um 10:12 UTCresolved

   Das Problem wurde behoben und die Lösungsbereitstellung im Studio Web funktioniert wie erwartet in der Region Japan. Es wurden keine weiteren Auswirkungen beobachtet.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 25. August 2026 um 03:58 UTCinvestigating

   Wir untersuchen ein Problem, das Kunden betrifft, die Insights in der Region Singapur verwenden, wo Dashboards möglicherweise keine Timeout-Fehler laden und anzeigen. Unsere Teams arbeiten daran, die Ursache zu identifizieren und werden weitere Updates bereitstellen, sobald mehr Informationen verfügbar sind.

2. 25. August 2026 um 04:37 UTCmonitoring

   Das Problem wurde gemildert, und wir beobachten den Insights-Service in der Region Singapur genau, um sicherzustellen, dass die Dashboards weiterhin wie erwartet geladen werden.

3. 25. August 2026 um 04:53 UTCresolved

   Das Problem wurde behoben und der Insights-Service in der Region Singapur funktioniert wie erwartet. Es wurden keine weiteren Auswirkungen beobachtet.

4. 4. September 2026 um 11:46 UTCpostmortem

   ## Customer Impact Zwischen dem 25. August 2026 um 3:42 Uhr UTC und dem 25. August 2026 um 4:53 Uhr UTC erlebten Kunden, die Insights in der Region Singapur nutzten, Ausfälle beim Laden von Insights-Dashboards. Betroffene Benutzer sahen, dass Dashboard-Seiten ausfallen oder nicht geladen werden, und Serverfehler wurden bei verwandten Serviceanforderungen beobachtet. Die primäre Auswirkung war der Zugriff auf das Insights-Dashboard, einschließlich Diagrammen und Warnungen. Ein verwandter Backend-Service gab auch Serverfehler während des Vorfalls zurück, aber der Dashboard-Zugriff war vor der endgültigen Auflösung wiederhergestellt. ## Wurzelursache Der Vorfall wurde auf eine regionale Störung des Microsoft-Dienstes in Singapur zurückgeführt, die sich auf die vom Insights-Dienst verwendete Infrastruktur auswirkte. Während der Störung konnte der Insights-Dienst Dashboard-Anforderungen nicht zuverlässig bedienen, was zu Anforderungs-Timeouts und Serverfehlern führte. Auf unserer Seite wurden keine Änderungen vorgenommen. Der Dienst erholte sich, als die regionale Störung von Microsoft behoben wurde, und Microsoft meldete anschließend ein Problem mit dem Regionaldienst in Singapur auf seiner Statusseite. Eine formale Ursachenanalyse wurde von Microsoft angefordert, um den spezifischen Fehlermechanismus zu bestätigen und zusätzliche Präventions- oder Minderungsmaßnahmen zu identifizieren. Detektion Automatisierte Gesundheitsüberwachung für den Insights-Service erkannte das Problem am 25. August 2026 um 3:42 Uhr UTC. Die Auswirkungen der Kunden wurden kurz nach der Erkennung auf der Reaktionsbrücke bestätigt. ## Antwort Am 25. August 2026 um 3:58 Uhr UTC haben wir ein öffentliches Status-Update veröffentlicht, in dem festgestellt wird, dass Insights-Dashboards in der Region Singapur möglicherweise keine Timeout-Fehler laden und anzeigen. Während der Antwort überprüfte unser Engineering-Team Serverfehler bei der automatisierten Überwachung, versuchte, auf die Service-Diagnose zuzugreifen, und begann ein Wiederherstellungsverfahren für die zugrunde liegende Infrastruktur. Am 25. August 2026 um 4:01 Uhr UTC erholte sich der Insights-Service, während das Wiederherstellungsverfahren im Gange war, und das Laden des Dashboards wurde über mehrere Testkonten hinweg validiert. Am 25. August 2026 um 4:37 Uhr UTC haben wir den Vorfall auf die Überwachung umgestellt, nachdem wir die erfolgreich geladenen Dashboards bestätigt hatten. Ein verwandter Backend-Service erholte sich am 25. August 2026 um 4:49 Uhr UTC, und der Vorfall wurde am 25. August 2026 um 4:53 Uhr UTC behoben. ## Follow-up 1. Fordern Sie eine Ursachenanalyse von Microsoft für die regionale Störung in Singapur an, die das Ladeproblem der Insights-Dashboards betrifft.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 25. August 2026 um 03:44 UTCinvestigating

   Wir untersuchen ein Problem, das Kunden betrifft, die die erweiterte OCR-Funktionalität im Document Understanding-Service in der Region Singapur nutzen. Unsere Teams arbeiten daran, die Ursache zu identifizieren und werden weitere Updates bereitstellen, sobald mehr Informationen verfügbar sind.

2. 25. August 2026 um 04:04 UTCmonitoring

   Das Problem wurde gemildert, und wir überwachen den Dienst genau, um sicherzustellen, dass er weiterhin wie erwartet funktioniert. Wir werden weitere Updates bereitstellen, sobald weitere Informationen verfügbar sind.

3. 25. August 2026 um 04:59 UTCresolved

   Das Problem wurde behoben und der Dienst funktioniert wie erwartet. Es wurden keine weiteren Auswirkungen beobachtet.

4. 27. August 2026 um 03:42 UTCpostmortem

   ## Customer Impact Am 25. August 2026 scheiterten Extended OCR Requests im Document Understanding Service mit 500 Statuscode in der Region Singapur für etwa 33 Minuten, zwischen 03:08 und 03:41 UTC. Die Ursache war eine Störung des regionalen Microsoft-Dienstes in Singapur. Alle anderen Document Understanding-Funktionalitäten waren nicht betroffen und keine andere Region war betroffen. ## Wurzelursache Der Fehler wurde auf eine regionale Störung des Microsoft-Dienstes in Singapur zurückgeführt, die sich auf die von der erweiterten OCR-Fähigkeit verwendeten Ressourcen auswirkte. Auf unserer Seite wurden keine Änderungen vorgenommen, und Microsoft aktualisierte daraufhin seine eigene Statusseite, um ein regionales Problem in Singapur widerzuspiegeln. Eine formale Ursachenanalyse wurde von Microsoft angefordert. Detektion Eine automatisierte Warnung für den Document Understanding Service wurde am 25. August 2026 um 3:13 Uhr UTC abgefeuert. Die Warnung wurde umgehend bestätigt und der Vorfall wurde innerhalb von Minuten als kundenrelevant erklärt. ## Antwort Der On-Call-Ingenieur untersuchte die Auswirkungen auf die Region Singapur. Responder schlossen ein kürzliches Service-Update als Ursache aus, da dasselbe Update in anderen Regionen ohne vergleichbare Auswirkungen bereitgestellt wurde, was auf einen regionalen Abhängigkeitsausfall außerhalb unserer Infrastruktur hindeutete. Da der Fehler in einem vorgelagerten Microsoft-Dienst entstand, war auf der UiPath-Seite keine Minderungsmaßnahme verfügbar oder erforderlich. Anfragen begannen um 03:41 UTC erneut erfolgreich zu sein, als sich die Microsoft-Abhängigkeit erholte. Die Responder hielten den Vorfall offen, um eine nachhaltige Erholung zu überprüfen: Zehn Minuten sauberer Verkehr wurden um 03:51 UTC bestätigt, der Vorfall wurde um 04:04 UTC zur Überwachung verschoben und wurde um 04:59 UTC nach fortgesetzter Stabilität ohne weitere Ausfälle behoben. ## Follow-up 1. Microsoft hat eine Ursachenanalyse für die regionale Störung in Singapur angefordert, die sich auf erweiterte OCR-Abhängigkeiten auswirkt, einschließlich der Frage, wie ein Wiederauftreten verhindert werden kann.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 24. August 2026 um 10:43 UTCidentified

   Wir haben die Ursache eines Problems identifiziert, das eine kleine Anzahl von Kunden betrifft, die UiPath-Apps verwenden, die über den Studio-Webdienst in mehreren Regionen erstellt wurden. Unsere Teams sind bereit für eine Lösung, und der Einsatz beginnt in den betroffenen Regionen. Wir werden die Bereitstellung weiterhin überwachen und weitere Updates bereitstellen, sobald der Fix in Kraft tritt.

2. 24. August 2026 um 11:30 UTCmonitoring

   Der Fix wurde erfolgreich in allen betroffenen Regionen eingesetzt und das Problem wurde gemildert. Wir beobachten den Service genau, um sicherzustellen, dass der Fix weiterhin wie erwartet funktioniert und werden bei Bedarf weitere Updates bereitstellen.

3. 24. August 2026 um 11:55 UTCresolved

   Das Problem wurde behoben und der Dienst funktioniert wie erwartet. Es wurden keine weiteren Auswirkungen beobachtet.

4. 1. September 2026 um 11:47 UTCpostmortem

   ## Customer Impact Zwischen dem 19. August 2026 um 14:33 Uhr UTC und dem 24. August 2026 um 11:30 Uhr UTC konnte eine Teilmenge von Kunden keine UiPath Apps-Projekte laden, die von Studio Web verfasst wurden. Betroffene Kunden erlebten eine vollständige Nichtverfügbarkeit von Apps-Projekten anstelle von Langsamkeit oder verminderter Leistung. Die Auswirkungen beschränkten sich auf eine kleine Gruppe von Kunden, deren Apps-Service in der Region Japan gehostet wurde. Die Gesamtdauer des Kundeneinflusses betrug ca. 4 Tage und 21 Stunden. ## Wurzelursache Die Hauptursache war eine Diskrepanz zwischen Studio Web und UiPath Apps. Am 19. August 2026 erhielt Studio Web ein geplantes Update in der EU-Region, das ein Framework-Upgrade beinhaltete. Das entsprechende Update der UiPath Apps, das das Framework-Upgrade enthält, wurde noch nicht für die Einheit im japanischen Maßstab bereitgestellt. Ein früheres Apps-Update, das bereits mit der neuen Framework-Version kompatibel war, wurde in allen Regionen außer Japan bereitgestellt, wo die Bereitstellung aus anderen Gründen verschoben wurde. Infolgedessen lief in der Region Japan noch eine ältere Apps-Version, die nicht mit dem aktualisierten Studio Web kompatibel war. Detektion Das Problem wurde von einem Kunden über sein UiPath-Kontoteam am 24. August 2026 um 9:36 Uhr UTC gemeldet. Ein Vorfall wurde um 10:21 Uhr UTC eröffnet, und ein öffentlicher Statusseitenvorfall wurde innerhalb einer Minute erklärt. Bestehende automatisierte Überwachung hat das Problem nicht erkannt, da es übereinstimmende Bereitstellungskombinationen validiert; die Verbesserung der Erkennung für gemischte Konfigurationen ist Teil unseres Folgeplans. ## Antwort Innerhalb weniger Minuten nach Eröffnung des Vorfalls identifizierten wir die Diskrepanz bei der Bereitstellung als Ursache und beschlossen, die Bereitstellung des entsprechenden UiPath-Apps-Updates für alle betroffenen Regionen zu beschleunigen und die Apps auf die bereits für betroffene Kunden bereitgestellte Studio-Webversion abzustimmen. Um 10:43 Uhr UTC haben wir ein öffentliches Status-Update veröffentlicht, das bestätigt, dass die Ursache identifiziert wurde und dass der Fix eingesetzt wurde. Um 10:52 Uhr UTC war der Einsatz für die verbleibenden Regionen im Gange, wobei mehrere Regionen bereits abgeschlossen waren. Um 11:30 Uhr UTC bestätigten wir, dass der Fix in allen betroffenen Regionen eingesetzt wurde, und markierten den Vorfall. Um 11:55 Uhr UTC, nachdem die Überwachung keine weiteren Auswirkungen zeigte, wurde der Vorfall als behoben markiert. ## Follow-up 1. Fügen Sie eine automatisierte Warnung bei der Produktionstelemetrie hinzu, um Ladefehler von Apps zu erkennen, die mit der zu bedienenden Studio-Webversion korrelieren. 2. Implementieren Sie eine synthetische Überwachung, die regelmäßig ein aus Studio Web erstelltes Apps-Projekt über repräsentative Kundenkonfigurationen und Warnungen bei Fehlern lädt. 3. Passen Sie die Release-Sequenzierung für eng gekoppelte Studio-Web- und Apps-Änderungen so an, dass abhängige Apps-Updates in allen Regionen vollständig bereitgestellt werden, bevor die neuere Studio-Web-Erfahrung den Kundenverkehr erreicht.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 21. August 2026 um 12:37 UTCmonitoring

   Es wurde ein Fix für das Problem implementiert, das sich auf die Dokumentenklassifizierung und -extraktion für das Dokumentenverständnis in den USA auswirkt, und wir überwachen derzeit die Ergebnisse.

2. 21. August 2026 um 13:36 UTCresolved

   Das Problem der Dokumentenklassifizierung und -extraktion für das Dokumentenverständnis in der US-Region wurde behoben. Nach einer Überwachungsperiode wird bestätigt, dass der Service gesund ist und normal funktioniert.

3. 27. August 2026 um 03:46 UTCpostmortem

   ## Customer Impact Zwischen dem 21. August 2026 um 11:05 Uhr UTC und dem 21. August 2026 um 12:18 Uhr UTC erlebte eine Teilmenge von Kunden gescheiterte Document Understanding-Operationen, einschließlich der Klassifizierung, Extraktion und Digitalisierung von Dokumenten. Die geschätzte Dauer des Teilausfalls betrug 48 Minuten. Die Auswirkungen beschränkten sich auf Kunden, die Document Understanding in der US-Region nutzen. ## Wurzelursache Der Vorfall wurde dadurch verursacht, dass die Failover-Konfiguration der Document Understanding-Speicherdatenbank während eines präventiven Datenbankskalierungsvorgangs in einen defekten Zustand überging. Das Scale-up wurde eingeleitet, nachdem sich die Datenbank ihrem Speicherlimit näherte. Während des Betriebs konnte die sekundäre Datenbank nicht skaliert werden, der versuchte Entfernen aus der Failover-Konfiguration scheiterte und der Datenbankplattformanbieter musste die Replikationsverbindung unterbrechen. Dadurch blieb die Failover-Konfiguration in einem vorübergehend nicht verfügbaren Zustand, was dazu führte, dass die Speicher- und Laufzeitdienste, die von dieser Datenbank abhängen, Anforderungen fehlgeschlagen haben. Detektion Der Vorfall wurde durch eine automatisierte Warnung für die Document Understanding Services erkannt, die am 21. August 2026 um 12:10 Uhr UTC bestätigt wurde. ## Antwort Bevor der kundenrelevante Vorfall gemeldet wurde, wurde die Skalierung der primären Datenbank abgeschlossen und der Datenbankplattformanbieter wurde für das sekundäre Datenbankproblem beauftragt. Nachdem die Failover-Konfiguration unterbrochen wurde, untersuchten wir die Umleitung der Dienstverbindung, konnten jedoch angesichts der aktuellen Konfiguration des Dienstes keinen sicheren, sofortigen Pfad identifizieren. Der Dienst wurde wiederhergestellt, indem die ungesunde sekundäre Datenbank gelöscht und die Failover-Konfiguration neu erstellt wurde. Bis zum 21. August 2026 um 12:37 Uhr UTC war der Fix implementiert und die Überwachung war im Gange. Um 13:36 Uhr UTC bestätigte die Überwachung, dass der Dienst gesund war, und der Vorfall wurde als behoben markiert. ## Follow-up 1. Fordern Sie eine Ursachenanalyse vom Datenbankplattformanbieter an, um festzustellen, warum die sekundäre Datenbank nicht skaliert werden konnte und warum die Fehlerbehebung für die Failover-Konfiguration eine Bruchreplikation erforderte. 2. Aktualisierung der Schwellenwerte und des Routings für die Datenbankspeicherung, damit Warnmeldungen früher zugewiesen und bearbeitet werden, einschließlich einer Warnung mit geringerem Schweregrad bei 75 % Nutzung und einer Warnung mit höherem Schweregrad bei 85 % Nutzung.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 19. August 2026 um 16:34 UTCinvestigating

   Wir untersuchen ein Problem, das einige Kunden betreffen könnte, die Claude Sonnet 4.6 in Agenten in der US-Region verwenden. Unser Engineering-Team arbeitet aktiv daran, das Problem zu verstehen und wird weitere Updates teilen, sobald mehr Informationen verfügbar sind.

2. 19. August 2026 um 16:40 UTCmonitoring

   Wir haben das Problem gemildert. Unser Engineering-Team ist am Morgen aktiv und wird weitere Updates teilen, sobald weitere Informationen verfügbar sind.

3. 19. August 2026 um 16:42 UTCmonitoring

   Wir haben das Problem gemildert. Unser Engineering-Team überwacht aktiv und wird weitere Updates teilen, sobald mehr Informationen verfügbar sind.

4. 19. August 2026 um 16:55 UTCresolved

   Das Problem ist gelöst.

5. 31. August 2026 um 12:41 UTCpostmortem

   ## Customer Impact Zwischen dem 19. August 2026 um 13:36 Uhr UTC und dem 19. August 2026 um 15:53 Uhr UTC erhielt eine Teilmenge von Kunden Fehler bei der Verwendung von Claude Sonnet 4.6 in Agenten. Der Aufprall dauerte ca. 2 Stunden und 17 Minuten. Die Auswirkungen waren auf Kunden, die Agenten in der US-Region nutzen. Fehler wurden auch für Claude Opus 4.6 und Claude Opus 4.5 beobachtet, die bei geringerem Volumen verwendet werden. --- ## Wurzelursache Im Rahmen einer geplanten Infrastruktur-Migration haben wir den Plattformdienst, der Modellanforderungen für Agenten regional auf ein neues Konfigurationsbereitstellungssystem umgestellt. Der neuen Konfigurationsquelle fehlten die Routing-Einträge für drei Claude-Modelle - Claude Sonnet 4.6, Claude Opus 4.6 und Claude Opus 4.5. Ohne diese Einträge konnte der Dienst kein gültiges Ziel für Anfragen an diese Modelle auflösen und sie mit Fehlern ablehnen. Andere Modelle waren nicht betroffen und dienten weiterhin normal. --- Detektion Das Problem wurde durch Kundeneskalationen am 19. August 2026 um 14:55 Uhr UTC erkannt - etwa 1 Stunde und 19 Minuten nach der ersten betroffenen Anfrage. Unser Ingenieurteam hat das Problem auf bestimmte Claude-Modelle ausgedehnt und mit der Untersuchung begonnen. Die öffentliche Statuskommunikation begann um 15:08 Uhr UTC. Unsere Alarmüberwachung basiert auf aggregierten Fehlerquoten. Obwohl fast alle Anfragen an die drei betroffenen Modelle fehlschlugen, stellten diese Modelle einen kleinen Anteil des Gesamtverkehrs in der Region dar, so dass das Gesamtsignal unsere Alarmschwellen nicht überschritten hat und das Problem nicht automatisch angesprochen wurde. Dies ist die Detektionslücke, die im folgenden Follow-up angesprochen wird. --- ## Antwort Um 15:25 Uhr UTC wurde die unvollständige Konfigurationsquelle als Ursache identifiziert und ein Fix gestartet. Um 15:47 Uhr UTC war die Bereitstellung des Fixes im Gange, und der Dienst wurde aktiv überwacht, als die Änderung eingeführt wurde. Um 15:59 Uhr UTC bestätigten die Serviceprotokolle, dass das Problem gemindert wurde, und um 16:00 Uhr UTC wurde die Fehlerrate mit 0% bestätigt. Der Vorfall wurde um 16:40 Uhr UTC gemindert markiert, und die vollständige Auflösung wurde um 16:55 Uhr UTC nach fortgesetzter Überwachung und Kundenbestätigung erklärt, dass der Dienst wie erwartet funktionierte. --- ## Follow-up Die Migration der Infrastruktur wurde in allen Regionen abgeschlossen und die Routing-Konfiguration wird nun aus einer einzigen Quelle verwendet, wodurch die Diskrepanz, die diesen Vorfall verursacht hat, beseitigt wird, so dass er sich nicht wiederholen kann. Automatisierte Überprüfungen werden eingeführt, um jedes unterstützte Modell in jeder Region kontinuierlich zu verifizieren, so dass ein nicht verfügbares Modell sofort erkannt und alarmiert wird - auch in Regionen mit geringerem Datenverkehr.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 18. August 2026 um 17:54 UTCinvestigating

   Wir untersuchen Berichte über einen Ausfall, der sich auf Fehler in der Expressionsauswertung im Zusammenhang mit den HITL-Task-Outputparametern für Asgentic Orchestratron bei Community-Benutzern in Europa auswirkt. Auswirkungen: Benutzer können möglicherweise keine HITL-Aufgaben ausführen Nächstes Update: Unsere Teams arbeiten daran, die Ursache und den Umfang zu verstehen und werden Updates nach Verfügbarkeit teilen.

2. 18. August 2026 um 20:31 UTCidentified

   Wir haben die Ursache für einen Ausfall identifiziert, der sich auf Expressionsbewertungen im Zusammenhang mit den HITL-Task-Outputparametern für Agentic Orchestration bei Community-Benutzern in Europa auswirkt. Auswirkung: Benutzer werden Fehler erleben, wenn sie einen Ausdruck mit dem HITL-Task-Ausgabeparameter haben. Nächstes Update: Unsere Teams arbeiten daran, die Ursache und den Umfang zu verstehen und werden Updates nach Verfügbarkeit teilen.

3. 18. August 2026 um 21:45 UTCidentified

   Wir haben den Fix identifiziert und die Entschließung ist im Gange. Nächstes Update: Unsere Teams arbeiten an dem Fix und werden Updates nach Verfügbarkeit teilen.

4. 18. August 2026 um 22:53 UTCmonitoring

   Wir haben den Fix eingesetzt und überwachen die Resolution. Nächstes Update: Unsere Teams überwachen die Auflösung und werden Updates nach Verfügbarkeit teilen.

5. 18. August 2026 um 23:25 UTCresolved

   Der Ausfall wurde behoben und Agentic Orchestration ist voll funktionsfähig. Auswirkungen: Keine anhaltenden Benutzerauswirkungen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 18. August 2026 um 12:08 UTCidentified

   Wir haben die Ursache eines Problems in Studio Web identifiziert, bei dem der Ressourcenkonfigurationsbildschirm zum Ändern von Ressourcenattributen nicht geladen wird. Wir stellen einen Fix bereit.

2. 18. August 2026 um 13:05 UTCidentified

   Die Bereitstellung des Fixes ist im Gange. Wir werden weitere Updates bereitstellen, wenn die Bereitstellung voranschreitet.

3. 18. August 2026 um 14:06 UTCidentified

   Der Fix wurde verifiziert und wird in allen verbleibenden Regionen eingeführt. Wir überwachen die Bereitstellung und Wiederherstellung. Vielen Dank für Ihre Geduld.

4. 18. August 2026 um 17:03 UTCidentified

   Der Rollout schreitet in den verbleibenden Regionen wie erwartet voran. Wir überwachen weiterhin den Einsatz. Vielen Dank für Ihre Geduld.

5. 18. August 2026 um 18:12 UTCmonitoring

   Der Rollout schreitet in den verbleibenden Regionen wie erwartet voran. Wir überwachen weiterhin den Einsatz. Vielen Dank für Ihre Geduld.

6. 18. August 2026 um 19:05 UTCresolved

   Der Rollout ist abgeschlossen und das Problem sollte gelöst werden.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 18. August 2026 um 05:32 UTCinvestigating

   Wir untersuchen ein Problem mit Community-Konten, bei denen neu erstellte Entitäten etwa eine Stunde benötigen, um im Studio Web zu erscheinen. Es gehen keine Daten verloren und bestehende Entitäten sind nicht betroffen.

2. 18. August 2026 um 06:48 UTCinvestigating

   Wir untersuchen das Problem weiter und arbeiten daran, die Ursache zu identifizieren und die normalen Bearbeitungszeiten wiederherzustellen.

3. 18. August 2026 um 08:44 UTCinvestigating

   Wir untersuchen weiterhin das Problem, das eine Untergruppe von Mietern in Europa, den Vereinigten Staaten und Japan betrifft, wo neu geschaffene Einheiten länger dauern können als erwartet, um im Studio Web zu erscheinen. Es gehen keine Daten verloren und bestehende Entitäten sind nicht betroffen.

4. 18. August 2026 um 09:37 UTCidentified

   Wir haben die Ursache identifiziert und arbeiten an einer Lösung für das Problem, das eine Untergruppe von Mietern in Europa, den Vereinigten Staaten und Japan betrifft. Vielen Dank für Ihre Geduld.

5. 18. August 2026 um 11:19 UTCmonitoring

   Das Problem wurde gemildert, und wir erwarten, dass sich die Bearbeitungszeiten in Kürze wieder normalisieren werden. Wir beobachten die Erholung genau. Vielen Dank für Ihre Geduld.

6. 18. August 2026 um 11:57 UTCresolved

   Das Problem wurde behoben und die Bearbeitungszeit hat sich wieder normalisiert. Vielen Dank für Ihre Geduld.

7. 27. August 2026 um 03:51 UTCpostmortem

   ## Customer Impact Zwischen dem 18. August 2026 um 5:11 Uhr UTC und dem 18. August 2026 um 11:57 Uhr UTC könnten neu erstellte Entitäten in einer Teilmenge von UiPath Cloud-Mandanten länger dauern als erwartet, um im Studio Web zu erscheinen. Zum Zeitpunkt der ersten Bewertung erschienen neu geschaffene Entitäten mit einer Verzögerung von etwa einer Stunde. Kunden in Europa, den USA und Japan waren betroffen. Die Entitätserstellung selbst ging erfolgreich weiter, es gingen keine Daten verloren und bestehende Entitäten blieben unberührt. ## Wurzelursache Das Problem wurde durch ein ungewöhnlich hohes Volumen von Asset-Erstellungsanfragen von einem Mieter verursacht. Diese Anfragen erzeugten mehr Ereignisse, als unser Backend-Entitätsindexierungsdienst mit der gleichen Rate verarbeiten konnte, wodurch ein Backlog in der Warteschlange für die Ereignisverarbeitung erstellt wurde. Da Studio Web auf diesen Dienst angewiesen ist, um neu erstellte Entitäten anzuzeigen, wurden neue Entitäten erst nach der Verarbeitung des Backlogs angezeigt. Detektion Das Problem wurde von unserem Engineering-Team durch die Verarbeitung von Latenzalarm identifiziert, und ein Vorfall wurde am 18. August 2026 um 5:11 Uhr UTC gemeldet. Um 5:23 Uhr UTC bestätigte die Analyse, dass die letzte verarbeitete Entität ungefähr eine Stunde zurücklag. ## Antwort Um 5:32 Uhr UTC haben wir ein erstes Kundenupdate mit verzögerter Sichtbarkeit für neu erstellte Entitäten im Studio Web veröffentlicht. Um 6:07 Uhr UTC identifizierte die Untersuchung einen ungewöhnlich hohen Traffic zur Erstellung von Vermögenswerten von einem Mieter, und um 7:03 Uhr UTC passten wir die Datenbankressourcen für den betroffenen Dienst an, um die Wiederherstellung der Verarbeitung zu unterstützen. Um 7:59 Uhr UTC hatte die Quelle des hohen Anforderungsvolumens das Senden von Anfragen gestoppt, und die Warteschlange begann zu leeren. Um 9:59 Uhr UTC starteten wir einen Datensynchronisationsprozess für den betroffenen Mandanten, und um 10:31 Uhr UTC entfernten wir die problematischen Warteschlangen, so dass die normale Verarbeitung schneller aufholen konnte. Die Warteschlangentiefe sank von 95.000 Artikeln um 8:34 Uhr UTC auf 1.000 Artikel um 11:44 Uhr UTC. Der Vorfall wurde um 11:19 Uhr UTC gemildert, nachdem die Verarbeitung erheblich wiederhergestellt wurde, und um 11:57 Uhr UTC aufgelöst, nachdem die Verarbeitungszeit wieder normal war. ## Follow-up Wiederauslösung der Datensynchronisation für den betroffenen Mandanten und Überwachung der Aufnahme, bis die Daten des Mandanten konsistent bestätigt werden. Verbessern Sie das Entity-Handling im Indexierungs-Backend, damit sich der Backlog nicht mit dieser Rate anhäuft.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 14. August 2026 um 21:24 UTCidentified

   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. 14. August 2026 um 23:22 UTCresolved

   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. 28. August 2026 um 16:55 UTCpostmortem

   ## 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.

1. 18. August 2026 um 10:58 UTCresolved

   Ein Sturm von Anfragen zu einer selten verwendeten Modellfunktion in IXP Communications Mining führte zu einer Wiederholungsschleife, um synchrone Anfragen in der breiteren IXP-API zu sperren. Dies führte dazu, dass Anfragen mit 500 fehlschlugen, da die Arbeiter mit lang laufenden Anfragen beschäftigt waren. Die automatische Skalierung erreichte schnell ihre maximale Kapazität und die Auflösung erfolgte nur durch Anwendung eines Code-Fixes, der strenge Timeouts für die beitragende API-Anforderung einführte. Der Anfragesturm begann um 15:10 UTC und erkannte eine 15:15 UTC durch automatische Alarme. Die Auflösung wurde um 18:15 UTC bestätigt. Der vorfall wurde zunächst fälschlicherweise nur dem client zugeschrieben, der den sturm der anfragen machte, aber später entdeckt wurde, dass er ein breiteres spektrum von nutzern beeinflusst hat. Gesamtauswirkungen begrenzt auf eine handvoll nutzer in den usa.

2. 18. August 2026 um 21:25 UTCpostmortem

   ## Customer Impact Am 12. August 2026, zwischen ca. 15:10 und 18:15 UTC, erlebten Benutzer von Communications Mining (IXP) in der Region der Vereinigten Staaten intermittierende Anforderungsfehler. Der Vorfall beschränkte sich auf eine der Bereitstellungseinheiten der Region, wo die Benutzer Fehler in Bursts von fünf bis zehn Minuten sahen, wobei bis zu 5-7 % ihrer Anfragen mit 5xx Fehlern in der Spitze scheiterten. Zwischen den Bursts funktionierte der Dienst normal, wiederholte Anfragen waren im Allgemeinen erfolgreich und es gingen keine Daten verloren. ## Wurzelursache Ein Sturm von Anfragen an eine selten verwendete API-Funktion, die Vorhersagen für maschinelles Lernen bei Bedarf berechnet, fiel mit einer wiederholten Umschulung des angeforderten Modells zusammen. Jede Umschulung hat zwischengespeicherte Vorhersagen ungültig gemacht und jede Anforderung in eine mehrminütige Berechnung umgewandelt. Die API legte keine zeitliche Begrenzung fest, wie lange eine Anforderung auf diese Berechnung warten konnte, so dass diese lang laufenden Anforderungen nach und nach die gesamte Anforderungsverarbeitungskapazität belegten, was dazu führte, dass nicht verwandte Anforderungen fehlschlugen. Die automatische Skalierung erreichte schnell ihre maximale Kapazität und konnte sie nicht kompensieren. Detektion Die automatisierte Überwachung erkannte die Fehler um 15:15 Uhr UTC, etwa fünf Minuten nach Beginn des Aufpralls, und stellte den Bereitschaftstechniker auf die Seite. Der Vorfall wurde ursprünglich nur dem Client zugeschrieben, der den Anfragesturm erzeugte, aber Clientberichte und weitere Untersuchungen zeigten, dass eine breitere Gruppe von Benutzern während der Fehlerstöße betroffen war. ## Antwort Der Bereitschaftstechniker verfolgte die Fehler auf das unbegrenzte Warten im On-Demand-Vorhersagepfad. Die Servicekapazität wurde wiederholt durch automatische Instanzersetzung wiederhergestellt, während ein Codefix entwickelt wurde. Der Fix ist ein strikter Timeout für die beitragende Anforderung, so dass er schnell fehlschlägt, ohne andere Anforderungen zu beeinträchtigen, und wurde um ca. 18:00 UTC in der betroffenen Region bereitgestellt und die Auflösung wurde um 18:15 UTC bestätigt. ## Follow-up 1. Der strikte Timeout- und Load-Shedding-Fix wurde dauerhaft gemacht und für alle Regionen freigegeben (abgeschlossen am 13. August 2026). 2. Bewerten Sie die Grenzen der On-Demand-Vorhersage, so dass die Nutzung eines einzelnen Clients die freigegebene API nicht beeinträchtigen kann.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 10. August 2026 um 14:11 UTCinvestigating

   Wir untersuchen eine verschlechterte Leistung, die sich auf Front-End Services im Dokumentenverständnis in der GXP East US Region auswirkt. Auswirkungen: Benutzer können Timeouts beim Zugriff auf die Benutzeroberfläche in GXP US bemerken. Nächstes Update: Zusätzliche Updates werden bereitgestellt, sobald weitere Informationen verfügbar sind.

2. 10. August 2026 um 14:25 UTCresolved

   Das Problem wurde behoben und die Leistung des Front-End-Service im Dokumentenverständnis ist auf das erwartete Niveau zurückgekehrt, nachdem sich die verschlechterte Leistung auf die Benutzeroberfläche in der Region GXP East US ausgewirkt hat. Auswirkungen: Keine anhaltenden Benutzerauswirkungen.

3. 19. August 2026 um 06:14 UTCpostmortem

   ## Customer Impact Zwischen dem 10. August 2026 um 13:21 UTC und dem 10. August 2026 um 14:03 UTC erlebte eine Teilmenge von Kunden eine beeinträchtigte Leistung und Timeouts beim Zugriff auf die Document Understanding-Benutzeroberfläche, die das Design-Zeit-Erlebnis bietet, in der verzögerten US-Region. Automatisierungen der Dokumentenverarbeitung waren nicht betroffen. ## Wurzelursache Während einer manuellen Bereitstellung von einem bereits vorhandenen Build des Dienstes hinter der Document Understanding-Benutzeroberfläche in die verzögerte US-Region hat unser Bereitstellungsprozess die Versionskennung für den bereitgestellten Dienst neu zugewiesen. Die Document Understanding-Schnittstelle erfordert, dass die unterstützenden Ressourcen unter der gleichen Versionskennung wie der bereitgestellte Dienst verfügbar sind. Da der Bereitstellungsprozess diesen Bezeichner geändert hat, konnte die Schnittstelle die erforderlichen Ressourcen nicht lokalisieren, wodurch sie unzugänglich wurde oder ausfällt. Detektion Wir wurden auf das Problem aufmerksam, sobald die Bereitstellung abgeschlossen war, durch manuelle Überprüfung als Teil der manuellen Bereitstellungs-Checkliste. Kurz darauf folgte eine automatisierte Warnung, die am 10. August 2026 um 13:28 Uhr UTC ausgelöst wurde. ## Antwort Nachdem wir den Grund für den Fehler der manuellen Bereitstellung identifiziert hatten, begann unser Engineering-Team mit der Bereitstellung eines korrigierten Updates mit den erforderlichen Ressourcen. Gleichzeitig wurde das Operationsteam beauftragt, ein manuelles Rollback des Einsatzes durchzuführen. Der Rollback wurde um 14:03 UTC abgeschlossen, wodurch der Zugang zum Design-Zeit-Erlebnis wiederhergestellt wurde. Um 14:11 Uhr UTC haben wir ein öffentliches Status-Update veröffentlicht, das eine beeinträchtigte Leistung und mögliche Timeouts in der Document Understanding-Benutzeroberfläche für die verzögerte US-Region anzeigt. Um 14:15 Uhr UTC war das korrigierte Update abgeschlossen und die Benutzeroberfläche wurde mit einer korrekten neuen Version und Funktion bestätigt. Um 14:25 UTC wurde der Vorfall als behoben markiert und die öffentliche Statusseite wurde aktualisiert, um zu bestätigen, dass die Leistung der Document Understanding-Schnittstelle auf das erwartete Niveau zurückgekehrt war. ## Follow-up 1. Wir reduzieren die Zeit, die für die Wiederherstellung einer früheren Version des Dienstes erforderlich ist, so dass die Wiederherstellung nach einer fehlgeschlagenen Bereitstellung schneller erfolgt. 2. Wir verbessern den manuellen Einsatzprozess, um eine zukünftige Situation zu verhindern, indem wir die Existenz der erforderlichen Ressourcen als Voraussetzung validieren.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 8. August 2026 um 11:54 UTCidentified

   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. 8. August 2026 um 13:01 UTCidentified

   Das Team arbeitet an der Servicewiederherstellung. Wir werden den Status aktualisieren, sobald die Minderung abgeschlossen ist.

3. 8. August 2026 um 14:14 UTCidentified

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

4. 8. August 2026 um 15:30 UTCidentified

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

5. 8. August 2026 um 15:32 UTCmonitoring

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

6. 8. August 2026 um 16:01 UTCresolved

   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. 12. August 2026 um 10:14 UTCpostmortem

   ## 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.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 6. August 2026 um 21:14 UTCresolved

   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. 13. August 2026 um 15:12 UTCpostmortem

   ## 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.