Störungsverlauf von Uipath

1. 27. Oktober 2026 um 16:39 UTCresolved

   Am 27. Oktober 2026, zwischen 14:35 und 16:08 UTC, erlebte Document Understanding in der Region Europa einen teilweisen Ausfall, der sich auf generative Extraktion, generative Klassifizierung und Autovalidierung auswirkte. Die Hauptursache war ein Verbindungsproblem mit einem Speicheranbieter eines Drittanbieters. Die Konnektivität wurde wiederhergestellt, und wir haben bestätigt, dass Extraktion und Klassifizierung seit 16:08 UTC normal funktionieren.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 26. Oktober 2026 um 14:04 UTCidentified

   Wir untersuchen derzeit ein Problem, das sich auf die Verfügbarkeit von Insights und Automatisierungsdiensten auswirkt. Unser Team bewertet die Situation aktiv, um die zugrunde liegende Ursache zu identifizieren und die notwendigen Schritte zur Wiederherstellung des normalen Betriebs zu bestimmen. Weitere Updates werden bereitgestellt, sobald mehr Informationen verfügbar werden.

2. 26. Oktober 2026 um 15:35 UTCidentified

   Das Problem mit Automation Ops wurde behoben. Wir warten derzeit darauf, dass das Problem mit dem Insights-Service gemildert wird. Weitere Updates werden geteilt, sobald sie verfügbar sind.

3. 26. Oktober 2026 um 17:09 UTCidentified

   Insights-Service in Singapur, Japan, Schweiz, Kanada, Indien, Großbritannien, Europa, Vereinigte Staaten, Vereinigte Arabische Emirate, Südkorea und Australien Region ist festgelegt und wir gelten fix auf andere Regionen

4. 26. Oktober 2026 um 18:27 UTCresolved

   Das Problem wurde behoben und alle Dienste funktionieren jetzt normal.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 27. Oktober 2026 um 10:13 UTCresolved

   Am 26. Oktober 2026, zwischen 10:20 und 17:30 UTC, erlebte Automation Cloud Robots (VM) einen teilweisen Ausfall, der den Maschinenbetrieb beeinträchtigte. Während dieses Fensters sind Aktionen wie Starten, Stoppen oder Bereitstellen von VM-Maschinen möglicherweise nicht abgeschlossen, und auf diesen Maschinen geplante Aufgaben wurden möglicherweise verzögert oder fehlerhaft ausgeführt. Die Ursache war eine Fehlkonfiguration von Berechtigungen in einer Teilmenge der zugrunde liegenden Infrastrukturressourcen. Unser Team identifizierte das Problem, korrigierte die Konfiguration und bestätigte, dass der Maschinenbetrieb seit 17:30 UTC normal funktioniert. Wir überprüfen, wie die Fehlkonfiguration eingeführt wurde, und fügen Kontrollen hinzu, um ein Wiederauftreten zu verhindern. Es ist keine Aktion auf Ihrer Seite erforderlich. Wenn Sie immer noch gescheiterte oder festgefahrene Jobs aus diesem Fenster sehen, versuchen Sie sie bitte erneut und wenden Sie sich an den Support, wenn das Problem weiterhin besteht.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 23. Oktober 2026 um 21:35 UTCresolved

   Zwischen 20:42 und 21:19 UTC am 23. Oktober sahen einige Orchestrator-Kunden in Europa langsame Reaktionen und intermittierende Fehler. Dazu gehörten Roboteranrufe, um Assets zu erhalten, Warteschlangen zu verarbeiten und den Jobstatus zu melden. Einige unbeaufsichtigte Jobs sind in dieser Zeit möglicherweise gescheitert. Die Ursache war ein plötzlicher Anstieg der Belastung, der die Ressourcengrenzen der Datenbank erreichte. Wir haben die Datenbankkapazität hinzugefügt, und die Leistung ist seit 21:19 UTC wieder normal. Kunden, deren Jobs in diesem Fenster fehlgeschlagen sind, müssen sie möglicherweise neu starten.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 22. Oktober 2026 um 12:59 UTCinvestigating

   Wir haben ein Problem identifiziert, das IXP für Kunden betrifft, die in der Region Australien gehostet werden. Seit 10:24 UTC scheitern Anfragen, die das Gemini 2.5 Flash-Modell verwenden, in der Region. Andere Modelle sind nicht betroffen. Kundendaten werden weiterhin nur innerhalb Australiens verarbeitet. Wir arbeiten mit Google zusammen, um den Service wiederherzustellen

2. 22. Oktober 2026 um 14:19 UTCmonitoring

   Ein Fix wurde bereitgestellt und der Dienst erholt sich. Wir überwachen das System, um eine vollständige Wiederherstellung zu gewährleisten. Weitere Updates werden in Kürze veröffentlicht

3. 22. Oktober 2026 um 14:33 UTCinvestigating

   Nach der anfänglichen Wiederherstellung hat sich der Dienst wieder verschlechtert. Wir untersuchen und arbeiten auf eine Lösung hin. Wir werden weitere Updates bereitstellen, sobald sie verfügbar sind.

4. 22. Oktober 2026 um 15:42 UTCinvestigating

   Wir haben den Google-Support kontaktiert und sie haben begonnen, nach ihrem Ende zu suchen. Wir werden weiterhin Updates überwachen und teilen, wie wir sie haben.

5. 22. Oktober 2026 um 17:56 UTCmonitoring

   Wir beobachten Verbesserungen beim Gemini 2.5 Flash-Verkehr. Wir überwachen einen möglichen Fix von Google.

6. 22. Oktober 2026 um 21:02 UTCresolved

   Das Problem wurde von Google gelöst.

7. 26. Oktober 2026 um 03:20 UTCpostmortem

   ## Customer Impact Zwischen dem 22. Oktober 2026 um 10:24 Uhr UTC und dem 22. Oktober 2026 um 18:04 Uhr UTC scheiterten Dokumentenverarbeitungsanforderungen, die Gemini 2.5 Flash in der Region Australien verwendeten, mit Kapazitätsfehlern. Der Aufprall dauerte etwa 7 Stunden und 40 Minuten. Eine Untergruppe von Kunden, die Dokumentenextraktions-Workflows in dieser Region verwenden, war betroffen. Während eines temporären In-Region-Fallback-Versuchs erholten sich einige Extraktionsanforderungen kurzzeitig, aber die Zuordnung auf Wortebene und der generierte Seitentext wurden abgebaut, bis auch der Fallback fehlschlug. ## Wurzelursache Die Hauptursache war eine anbieterseitige regionale Netzwerkstörung während der gleichzeitigen Wartung. Dies führte zu einer starken Bandbreitendrosselung in der modellführenden Umgebung des Anbieters, die verhinderte, dass die Backend-Systeme die Modelldaten laden konnten, die erforderlich waren, um Gemini 2.5 Flash- und Gemini 3.5 Flash-Anforderungen zuverlässig in der betroffenen Region zu bedienen. Detektion Das Problem wurde durch automatisierte Alarmierung erkannt, die Ratenbegrenzungsfehler bei Gemini 2.5 Flash in der Region Australien identifizierte. Unser Engineering-Team bestätigte durch Telemetrie, dass betroffene Anfragen konsequent fehlschlugen und begann, eine Antwort zu koordinieren. ## Antwort Um 13:40 Uhr UTC leiteten wir den betroffenen Gemini 2.5 Flash-Datenverkehr zu Gemini 3.5 Flash innerhalb derselben Region weiter, um die Datenresidenz zu erhalten. Erste Telemetrie zeigte keine Kapazitätsfehler nach dieser Änderung, aber um 14:10 Uhr UTC, Gemini 3.5 Flash gab auch Kapazitätsfehler zurück, so dass der Fallback nicht mehr tragfähig war. Um 14:05 Uhr UTC haben wir die verwandten Dokumentenverarbeitungspfade angepasst, so dass Attribution und Seitentextgenerierung das gleiche In-Region-Fallback verwenden würden; Diese Anpassung wurde um ungefähr 14:09 Uhr UTC abgeschlossen. Nachdem auch der Fallback fehlschlug, kehrten wir die Routing-Änderung zurück und um 16:28 Uhr war der UTC-Verkehr wieder auf dem erwarteten Gemini 2.5 Flash-Pfad. Um 17:38 Uhr UTC zeigte die Telemetrie eine Verbesserung der Gemini 2,5 Flash-Erfolgsraten. Ab 18:04 Uhr UTC wurden keine weiteren Kapazitätsfehler beobachtet und nachfolgende Anfragen waren erfolgreich. ## Follow-up 1. Füllen Sie die Kapazitätsbewertung des reservierten Modells für die betroffene Region unter Verwendung der beobachteten Verkehrsmuster aus 2. Bewertung des Retry- und Backoff-Verhaltens bei Dokumentenverarbeitungsclients, um die Retry-Verstärkung bei anbieterseitigen Kapazitätsausfällen zu reduzieren.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 15. Oktober 2026 um 12:27 UTCinvestigating

   Seit ca. 11:17 UTC haben Kunden in mehreren Regionen Probleme mit UiPath Agents and Solutions Management. Neue Jobs können im ausstehenden Status verbleiben, und laufende Agenten können Verzögerungen bei der Verarbeitung von Eskalationen oder beim Warten auf Werkzeugergebnisse erfahren. Wir untersuchen das Problem und arbeiten an einer Lösung.

2. 15. Oktober 2026 um 13:04 UTCmonitoring

   Das Problem wurde gemildert. Wir überwachen die betroffenen Dienste in allen Regionen, um Stabilität zu gewährleisten und zu bestätigen, dass Jobstarts und Lösungsbereitstellungen normal funktionieren.

3. 15. Oktober 2026 um 13:22 UTCresolved

   Dieser Vorfall wurde behoben. Zwischen 11:15 und 12:45 UTC am 15. Oktober verhinderte ein internes Konfigurationsproblem, dass einige Ereignisse zwischen UiPath-Diensten in mehreren Regionen geliefert wurden. Das Problem wurde behoben, indem die Änderung zurückgenommen wurde, und neue Aktivitäten werden normal verarbeitet. Einige Arbeiten, die während dieses Fensters begonnen oder ausgeführt werden, erfordern möglicherweise Aufmerksamkeit: Agenten: Agenten, die auf Action Center-Aufgaben oder Ergebnisse von Automatisierungstools warten, bleiben möglicherweise stecken. Jobs, die von Orchestrator gestartet wurden, können auch stecken bleiben oder ausfallen. Maestro: Prozesse, die auf Benutzeraufgaben warten, werden nach Abschluss der Aufgabe möglicherweise nicht wieder aufgenommen. Apps: Der Status von Warteschlangenelementen ist möglicherweise veraltet, und Aktionen, die durch den Abschluss von Warteschlangenelementen ausgelöst wurden, sind möglicherweise nicht ausgeführt worden. Autopilot für alle: Gespräche, die auf Automatisierungsergebnisse warten, bleiben möglicherweise blockiert. Document Understanding und Context Grounding: Automatisierungen und Agenten, die auf Extraktion, Validierung oder Indexierung warten, können ausgesetzt bleiben. - Integrationsdienst: Konnektorereignisse haben möglicherweise nicht die erwarteten Prozesse oder Benachrichtigungen ausgelöst. Lösungen und Studio-Web: Lösungsinstallationen, -deinstallierungen, -veröffentlichungen, -bereitstellungen und -validierungen, die während dieses Fensters eingeleitet wurden, sind möglicherweise fehlgeschlagen oder zeitversetzt. Das Wiederholen dieser Operationen kann das Problem lösen. Wir entschuldigen uns für die Störung und danken Ihnen für Ihre Geduld.

4. 21. Oktober 2026 um 06:47 UTCpostmortem

   **Kunde Auswirkungen ** Am 15. Oktober 2026, von 11:15 bis 12:50 UTC (ca. 1 Stunde und 35 Minuten), wurden einige Ereignisse, die zwischen UiPath-Cloud-Diensten ausgetauscht wurden, nicht geliefert. Kunden in allen kommerziellen Cloud-Regionen waren betroffen. Während dieses Fensters: - Neue Agentenläufe könnten im ausstehenden Status bleiben. Laufende Agenten, die auf ein Werkzeugergebnis, eine menschliche Eskalation, Dokumentenextraktion oder Kontexterdung warten, werden möglicherweise nicht wieder aufgenommen. Konversationsagenten und Autopilot für alle Gespräche, die eine Automatisierung gestartet haben, haben möglicherweise nicht ihr Ergebnis erhalten. Maestro-Prozessinstanzen, die auf eine Benutzeraufgabe warten, sind möglicherweise nach Abschluss der Aufgabe nicht weitergekommen, und Prozesse, die durch Integration Service-Verbindungsereignisse ausgelöst wurden, haben möglicherweise nicht begonnen. Apps, die den Status von Warteschlangenelementen anzeigen oder darauf reagieren, können veraltete Informationen anzeigen. - Installationen, Deinstallationen, Veröffentlichungen und Bereitstellungen von Lösungen können fehlschlagen oder ausfallen. Einige Benutzer-, Gruppen- und Ordneränderungen, die im Fenster vorgenommen wurden, wurden möglicherweise nicht an alle Dienste weitergeleitet. Die Arbeit begann nach 12:50 UTC war nicht betroffen. Roboter-Jobausführung, Warteschlangen und Trigger, die im Orchestrator gehandhabt wurden, funktionierten normal. **Wurzelursache** Wir verlagerten die Bereitstellung der internen Servicekonfiguration auf einen neuen Mechanismus, eine Änderung, die keine Auswirkungen auf die Kunden haben sollte. Als diese Änderung auf den Ereignisbereitstellungsdienst angewendet wurde, fehlte der von ihm erstellten Konfiguration ein erforderlicher Wert. Ohne sie behandelte der Service mehrere Produktintegrationen als ausgeschaltet und hörte stillschweigend auf, ihre Ereignisse zu liefern. Da der Wechsel alle Produktionsregionen gleichzeitig erreichte, war jede Region betroffen. **Erkennung** Das Problem wurde um 11:51 UTC, etwa 35 Minuten nach Beginn des Aufpralls, erkannt, als die Überwachung auf Agentenjobs aufmerksam gemacht wurde, die im ausstehenden Status blieben. Es folgten Berichte über das Timing der Lösungsbereitstellungen, und um 12:12 UTC wurde ein Vorfall gemeldet. **Antwort** Nach der ersten Erkennung um 11:51 UTC wurde die Konfigurationsänderung erkannt und um 12:00 UTC ein Rollback gestartet. Ein anfängliches Rollback um 12:14 UTC stellte die Lieferung nicht vollständig wieder her. Das Team stoppte dann den neuen Konfigurationsbereitstellungsprozess und stellte die vorherige Konfiguration wieder her. Die Lieferung der Veranstaltung begann sich um 12:40 UTC zu erholen, und die vollständige Erholung in allen Regionen wurde um 12:50 UTC bestätigt. Wo möglich, haben wir verpasste Ereignisse wiederholt, damit die betroffene Arbeit fortgesetzt werden kann. **Follow up** 1. Der neue Konfigurationsbereitstellungsprozess wurde für den betroffenen Dienst angehalten und bleibt angehalten, bis die Konfiguration korrekt generiert wurde. 2. Validierung der vom neuen Bereitstellungsmechanismus erstellten Konfiguration für die erforderlichen Werte, bevor sie in einer beliebigen Umgebung angewendet wird. 3. Führen Sie Änderungen an der Konfigurationsbereitstellung schrittweise über Regionen hinweg statt auf alle Regionen gleichzeitig aus. 4. Verbessern Sie unsere Überwachung, um innerhalb von Minuten zu erkennen, wenn Ereignisse nicht mehr an eine Produktintegration geliefert werden, die sie normalerweise empfängt. 5. Verbessern Sie unsere Fähigkeit, Ereignisse, die während einer Störung verpasst wurden, wiederherzustellen und erneut zu liefern.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 15. Oktober 2026 um 12:03 UTCresolved

   Einige Kunden in der US-Region erlebten Verzögerungen bei der Aufnahme von Roboterprotokollen, wobei eine erhöhte Aktivität zwischen etwa 11:20 und 11:45 UTC beobachtet wurde. Das Problem wurde behoben und die Protokollaufnahme hat sich wieder normalisiert. Vielen Dank für Ihre Geduld.

2. 22. Oktober 2026 um 10:13 UTCpostmortem

   ## Customer Impact Zwischen dem 15. Oktober 2026 um 23:20 Uhr UTC und dem 15. Oktober 2026 um 23:45 Uhr UTC erlebten einige Kunden in der US-Ostregion Verzögerungen bei der Roboterprotokollaufnahme im UiPath Orchestrator. Roboterprotokolle waren während des betroffenen Zeitraums nicht auf dem neuesten Stand. Der Aufprall dauerte etwa 20 Minuten. ## Wurzelursache Während des Vorfalls wurde beobachtet, dass 2 der 13 Serviceinstanzen, die die Roboterprotokollaufnahme handhaben, keine Verbindung zum Ereignisaufnahmedienst herstellen konnten. Nur Anfragen an den Ereignisaufnahmedienst scheiterten und nur in diesen beiden Fällen. Dies führte dazu, dass einige Anfragen zur Aufnahme von Roboterprotokollen nicht erfolgreich abgeschlossen wurden, was zu verzögerten Protokolldaten für betroffene Kunden führte. Die Ursache, warum nur diese beiden Instanzen die Verbindung zum Ereignisaufnahmedienst verloren haben, wurde während des Vorfalls nicht ermittelt. Das Team verpflichtete sich zu einer Überprüfung der Protokolle der betroffenen Instanzen nach dem Vorfall, um die zugrunde liegende Ursache zu identifizieren. Wir glauben, dass es sich um ein nicht gemeldetes Infrastrukturproblem unseres Cloud-Anbieters handelt. Detektion Das Problem wurde am 15. Oktober 2026 durch eine automatisierte Warnung um ca. 23:33 Uhr UTC erkannt und durch Telemetrie bestätigt, die Ausnahmen von den beiden betroffenen Dienstinstanzen zeigte. ## Antwort Nach der Erkennung bestätigte die Telemetrie, dass nur zwei Dienstinstanzen Ausnahmen erzeugten. Responder entfernten diese beiden ungesunden Instanzen aus dem Dienst und Ersatzinstanzen starteten automatisch. Innerhalb von etwa 20 Minuten nach dem ersten Alarm - um etwa 23:53 Uhr UTC - zeigte Telemetrie Erholung und synthetische Überwachung Kontrollen vorbei waren. Ein breiterer Neustart aller Serviceinstanzen wurde in Betracht gezogen, aber nicht durchgeführt, da das Team feststellte, dass es nicht weitergehen sollte, ohne zuerst die Ursache zu verstehen. ## Follow-up 1. Eine Überprüfung der Protokolle der betroffenen Dienstinstanzen nach dem Vorfall ergab, dass das Problem infrastrukturbedingt war, und wir verfolgen den Cloud-Infrastrukturanbieter für weitere Details. 2. Eine Aktualisierung wird veröffentlicht, wenn die Untersuchung zu weiteren Ergebnissen führt.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 14. Oktober 2026 um 07:26 UTCmonitoring

   Ab 6:50 UTC haben wir einen globalen Ausfall erlebt, der das Laden von Apps und codierten Apps in allen Regionen außer Indien und Großbritannien beeinflusst hat. Der Ausfall wurde behoben und die Dienste sind voll funktionsfähig. Auswirkungen: Keine anhaltenden Benutzerauswirkungen.

2. 14. Oktober 2026 um 07:43 UTCresolved

   Ab 6:50 UTC haben wir einen globalen Ausfall erlebt, der das Laden von Apps und codierten Apps in allen Regionen außer Indien und Großbritannien beeinflusst hat. Der Ausfall wurde behoben und die Dienste sind voll funktionsfähig. Auswirkungen: Keine anhaltenden Benutzerauswirkungen.

3. 23. Oktober 2026 um 12:08 UTCpostmortem

   ## Customer Impact Zwischen 06:38 UTC und 07:21 UTC am 14. Oktober 2026 scheiterte ein Teil der Anfragen an UiPath Apps, Coded Apps und davon abhängige Lösungen in elf Regionen: Europa, USA, Gemeinschaft, Japan, Singapur, Australien, Kanada, Südkorea, Schweiz, Vereinigte Arabische Emirate und das verzögerte US-Umfeld. Die Regionen Indien und Großbritannien waren nicht betroffen. Etwa 2 Prozent der Anfragen scheiterten insgesamt, je nach Region zwischen 0,6 und 5 Prozent. Betroffene Benutzer sahen, dass Anwendungen nicht geladen werden, Serverfehler zurückfordern oder langsame Antworten. In Regionen, in denen Service-Pods neu gestartet werden mussten, waren Apps bis zu acht Minuten lang nicht erreichbar. Die Reaktionszeiten waren in jeder Region um 07:40 UTC wieder normal. Die meisten Benutzer von bereits laufenden veröffentlichten Apps bemerkten wenig oder nichts. App-Definitionen werden bis zu 24 Stunden im Browser zwischengespeichert, App-Daten stammen aus Data Service und Orchestrator und nicht aus dieser Datenbank, und der Dienst wird über die bereits vorhandenen Datenbankverbindungen gespeichert. Die fehlgeschlagenen Anfragen waren diejenigen, die eine neue Datenbankverbindung benötigten: Öffnen der Liste des Designers oder der Apps, Laden einer noch nicht zwischengespeicherten App, Herunterladen von in Apps gespeicherten Dokumenten und Bildern und Speichern oder Veröffentlichen. ## Wurzelursache Um 06:38 UTC, während der Datenbankzugriff für eine neue regionale Bereitstellung eingerichtet wurde, wurde das Passwort des Datenbankbenutzers, den der Apps-Dienst verwendet, geändert. Dieser Benutzer wird von den Produktionsdatenbankclustern aller betroffenen Regionen geteilt, so dass die Änderung auf alle gleichzeitig angewendet wird. Die laufenden Dienste hielten weiterhin das vorherige Passwort und konnten keine neuen Datenbankverbindungen mehr öffnen. Die Regionen Indien und Großbritannien verwenden diesen Nachweis nicht und waren nicht betroffen. Die Änderung sollte einen separaten Datenbankbenutzer für die neue Region erstellen. Stattdessen wurde das Passwort des bestehenden Benutzers, das alle Regionen teilen, geändert. Unser Änderungsprozess für Datenbankanmeldeinformationen trennte die Erstellung einer neuen Anmeldeinformationen nicht eindeutig von der Änderung einer bestehenden Anmeldeinformationen und erforderte keine Überprüfung, wie viele Cluster und Regionen eine Anmeldeinformationenänderung beeinflussen würde. In Kombination mit einem einzelnen Datenbankbenutzer, der regionenübergreifend geteilt wird, ermöglichte dies eine Änderung, die für eine Region bestimmt ist, um einen Multi-Region-Ausfall zu verursachen. Detektion Unsere interne Überwachung erhöhte die erste Warnung um 06:41 UTC, drei Minuten nach den ersten Ausfällen, und Warnungen für jede betroffene Region, gefolgt von 06:46 UTC. Um 06:50 UTC bestätigte der Bereitschaftsingenieur, dass jeder Produktionscluster von seiner Datenbank abgelehnt wurde, und startete den Vorfallprozess. ## Antwort Um 07:05 UTC wurde das vorherige Passwort wiederhergestellt und Authentifizierungsfehler wurden überall gestoppt. Die meisten Regionen werden automatisch wieder verbunden. In den Regionen, in denen dies nicht der Fall war, wurden die Service-Pods neu gestartet oder neu eingesetzt: USA um 07:21 UTC und Schweiz um 07:30 UTC verzögert. Die Fehlermeldungen wurden um 07:21 Uhr UTC gestoppt, die Antwortzeiten waren bis 07:40 Uhr UTC wieder am Ausgangswert und wir überwachten weiter, bis der Vorfall um 07:43 Uhr UTC behoben wurde. ## Follow-up Um zu verhindern, dass sich dies wiederholt, sind wir: Einführung eines definierten Verfahrens zum Erstellen und Rotieren von Datenbankanmeldeinformationen mit einer Voränderungsüberprüfung, die angibt, welche Cluster und Regionen die Anmeldeinformationen gemeinsam nutzen, und einem schrittweisen Rollout, der in einer Region verifiziert wird, bevor er breiter angewendet wird. Umzug zu separaten, am wenigsten privilegierten Datenbankbenutzern für jede Region, so dass eine Änderung in einer Region keine andere beeinflussen kann. Automatisches Deklarieren eines Vorfalls und Paging der Datenbankbesitzer, wenn derselbe Datenbankfehler in mehreren Regionen gleichzeitig erkannt wird, anstatt sich auf eine manuelle Eskalation einzelner regionaler Warnmeldungen zu verlassen. - Ermöglicht es Diensten, aktualisierte Datenbankanmeldeinformationen ohne Neustart abzuholen und nach einem Authentifizierungsfehler eine schnellere Verbindung herzustellen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 13. Oktober 2026 um 14:03 UTCinvestigating

   Wir untersuchen derzeit einen Ausfall von UiPath Cloud-Diensten in mehreren Regionen. Benutzer können nicht auf Dienste zugreifen, die in den betroffenen Regionen gehostet werden. Nächstes Update: Zusätzliche Informationen werden geteilt, sobald sie verfügbar sind.

2. 13. Oktober 2026 um 14:37 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen.

3. 13. Oktober 2026 um 14:42 UTCinvestigating

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse. Das Problem beschränkte sich auf Document Understanding, Computer Vision, Semantic Proxy, Autopilot Studi, IXP. Wir werden ein weiteres Update teilen, sobald die Dienste vollständig wiederhergestellt sind.

4. 13. Oktober 2026 um 15:10 UTCinvestigating

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

5. 13. Oktober 2026 um 15:19 UTCresolved

   Dieser Vorfall wurde nach der Erneuerung des abgelaufenen SSL-Zertifikats behoben, das mehrere ML-abhängige Dienste betraf, darunter IXP, Document Understanding, Computer Vision, Semantic Proxy und Autopilot für Entwickler. Die Servicewiederherstellung hat in den betroffenen Regionen Fortschritte gemacht, und automatisierte Warnungen wurden konfiguriert, um das Ablaufen von Zertifikaten im Voraus zu erkennen und ähnliche Störungen in Zukunft zu verhindern. Vielen Dank für Ihre Geduld und Ihr Verständnis.

6. 26. Oktober 2026 um 03:17 UTCpostmortem

   ## Customer Impact Zwischen 13:37 und 14:40 UTC am 13. Oktober 2026 konnten Kunden in mehreren Regionen IXP Unstructured Documents, IXP Communications Mining und Document Understanding nicht verwenden. Computer Vision und Autopilot für Entwickler-Funktionen, die von den gleichen maschinellen Lerndiensten abhängen, sind ebenfalls fehlgeschlagen. Betroffene Kunden sahen, dass Anfragen mit "500 Internal Server Error"-Antworten oder Timeout, IXP-Projekten, die nicht geöffnet wurden, und Computer Vision-Aktivitäten, die bei der Ausführung von Automatisierungen fehlgeschlagen sind, fehlgeschlagen sind. Der Service wurde für ca. 1 Stunde unterbrochen. Es gingen keine Kundendaten verloren. ## Wurzelursache Der Vorfall wurde durch ein abgelaufenes Sicherheitszertifikat verursacht, mit dem sichere Verbindungen zu diesen Diensten hergestellt wurden. Das Zertifikat wird durch einen automatisierten Prozess erneuert. Dieser Prozess wurde nicht mehr erfolgreich ausgeführt und die Fehler lösten keine Warnung aus, so dass das Zertifikat nicht vor seinem Ablauf ersetzt wurde. Sichere Verbindungen zu den betroffenen Diensten wurden ab 13:37 UTC abgelehnt. Detektion Die automatisierte Überwachung begann, um 13:40 UTC auf Fehler und fehlenden Verkehr aufmerksam zu machen, und der Vorfall wurde um 13:54 UTC gemeldet. Das abgelaufene Zertifikat wurde um 14:00 Uhr UTC identifiziert und die erste Statusseite wurde um 14:03 Uhr UTC veröffentlicht. Keine Warnung warnte, dass das Zertifikat sich dem Ablauf näherte, und die wiederholten Ausfälle der automatisierten Erneuerung wurden dem Besitzerteam nicht gemeldet, so dass das Problem nur erkannt wurde, wenn die Kunden betroffen waren. ## Antwort Um 14:06 UTC bestätigte das Team, dass das Zertifikat abgelaufen war, weil die automatisierte Erneuerung fehlgeschlagen war. Um 14:18 UTC wurde ein neuer Nachweis für den Erneuerungsprozess ausgestellt. Die Erneuerung wurde manuell um 14:19 Uhr UTC gestartet und um 14:33 Uhr UTC abgeschlossen, und bis 14:37 Uhr UTC war jeder kundenorientierte Endpunkt verifiziert worden, um das erneuerte Zertifikat zu bedienen. Der Verkehr kehrte um ca. 14:40 UTC auf das normale Niveau zurück. Nach einer Zeit der Überwachung wurde der Vorfall um 15:19 UTC gelöst. ## Follow-up Um ähnliche Vorfälle in Zukunft zu verhindern, nehmen wir folgende Verbesserungen vor: - Warnen Sie rechtzeitig vor dem Auslaufen eines dieser Zertifikate. Benachrichtigen Sie das Besitzerteam, wenn die automatisierte Verlängerung fehlschlägt. Fügen Sie Überprüfungen hinzu, die alarmieren, sobald sichere Verbindungen zu diesen Diensten fehlschlagen. - Stärkung des Eigentums am Prozess der Zertifikatsverlängerung und der Anmeldeinformationen, auf die es angewiesen ist.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 13. Oktober 2026 um 10:32 UTCinvestigating

   Wir untersuchen ein Problem, bei dem Roboterausführungsprotokolle im Orchestrator nicht angezeigt werden. Wir arbeiten daran, den vollen Umfang und die Ursache zu bestimmen.

2. 13. Oktober 2026 um 10:57 UTCresolved

   Dieses Problem ist gelöst. Roboterausführungsprotokolle werden synchronisiert und sind in Orchestrator wieder für Japan Orchestrator sichtbar. Vielen Dank für Ihre Geduld.

3. 22. Oktober 2026 um 13:25 UTCpostmortem

   ## Customer Impact Zwischen etwa 07:00 UTC am 9. Oktober 2026 und 10:45 UTC am 13. Oktober 2026 erschienen etwa 6% der Roboterprotokolleinträge für Kunden in der Region Japan nicht in Orchestrator. Jobausführung und alle anderen Orchestrator-Funktionalitäten waren nicht betroffen. Fehlende Einträge wurden im Orchestrator sichtbar, nachdem das Problem behoben wurde. ## Wurzelursache Roboterprotokolle werden in einer Warteschlange platziert, die in 32 Partitionen aufgeteilt ist, und ein Ingestion-Service liest jede Partition und speichert die Protokolle für Orchestrator. Am 9. Oktober hörte der Ingestion-Service in der Region Japan auf, von 2 der 32 Partitionen zu lesen, ohne einen Fehler zu melden. Logs auf diesen Partitionen wurden in der Warteschlange gehalten, aber nicht gespeichert, so dass sie nicht in Orchestrator erschienen. Unsere Überwachung überprüfte den Dienst als Ganzes, nicht jede Partition, so dass das Problem nicht automatisch erkannt wurde. Detektion Das Problem wurde durch Kundenberichte erkannt. Wir erklärten einen Vorfall um 10:13 UTC am 13. Oktober und veröffentlichten eine Statusseite Benachrichtigung um 10:32 UTC. ## Antwort Wir haben den Ingestion-Service um ca. 10:41 UTC neu gestartet und alle Partitionen erneut gelesen. Die Protokolle in der Warteschlange wurden dann verarbeitet und wurden im Orchestrator sichtbar. Der Vorfall wurde um 10:57 UTC gelöst. ## Follow-up * Wir fügen eine Überwachung hinzu, die uns warnt, wenn eine einzelne Partition nicht mehr gelesen wird, so dass diese Art von Problem innerhalb von Minuten erkannt wird.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 7. Oktober 2026 um 21:34 UTCinvestigating

   Wir untersuchen Berichte über einen Ausfall, der sich auf HITL-Task-Erstellungsfehler für Maestro in den USA auswirkt. Auswirkungen: Benutzer können möglicherweise keine HITL-Aufgaben erstellen. Nächstes Update: Unsere Teams arbeiten daran, die Ursache und den Umfang zu verstehen und werden Updates nach Verfügbarkeit teilen.

2. 8. Oktober 2026 um 01:30 UTCidentified

   Wir haben die Ursache für einen Ausfall identifiziert, der sich auf die HITL-Aufgabenerstellung für Maestro in den USA auswirkt, und arbeiten daran, das Problem zu mildern. Auswirkungen: Benutzer können möglicherweise keine HITL-Aufgaben erstellen. Nächstes Update: Unsere Teams arbeiten daran, das Problem zu beheben und werden Updates nach Verfügbarkeit teilen.

3. 8. Oktober 2026 um 03:28 UTCmonitoring

   Wir führen eine Korrektur für einen Ausfall aus, der sich auf die HITL-Taskerstellung für Maestros mit HITL-Task-SLA-Timern auswirkt, die in den USA konfiguriert sind, und arbeiten daran, das Problem zu beheben. Auswirkungen: Benutzer können möglicherweise keine HITL-Aufgaben in Maestros mit konfigurierten HITL-Task-SLA-Timern erstellen. Nächstes Update: Unsere Teams arbeiten daran, das Problem zu beheben und werden Updates nach Verfügbarkeit teilen.

4. 8. Oktober 2026 um 04:29 UTCresolved

   Die Behebung des Problems, das sich auf die HITL-Taskerstellung für Maestro mit HITL-Task-SLA-Timern auswirkt, die in den USA konfiguriert sind, wurde vollständig ausgerollt. Die HITL-Aufgabenerstellung ist wieder normal.

5. 26. Oktober 2026 um 03:16 UTCpostmortem

   ## Customer Impact Am 2026-10-05 zwischen 9.30 Uhr UTC - 2026-10-07 3.30 Uhr UTC-, Maestro-BPMN- und Case-Kunden, die HITL-Knoten mit einem konfigurierten Task-Timer verwenden, sahen mit 4xx Ausfälle ihrer Debug- und Produktionsinstanzen in der HITL-Phase. Es wurden etwa 30 solcher Instanzen bei Kunden in den USA und Europa identifiziert, die ohne Workaround blockiert wurden. ## Wurzelursache Die Konfiguration eines Task-SLA erfordert ein Objekt, das die Start- und Endkriterien, den Timer des SLA und das Ergebnis eines SLA-Verstoßes enthält. Kunden konfigurieren dies auf dem Maestro-Designer auf dem HITL-Knoten. Das Ergebnis wurde fälschlicherweise nicht obligatorisch auf der Designoberfläche gehalten, obwohl eine SLA-Konfiguration ohne Ergebnis nicht fortbesteht und keinen geschäftlichen Sinn ergibt. Das Action Center-Backend-Team hatte eine Validierung hinzugefügt, um eine fehlerhafte Anfrage (400) im Falle eines nicht nullen SLA-Objekts mit einem fehlenden Ergebnis zu werfen. Dies wirkte sich auf Kunden aus, die die Start-/End-Kriterien auf dem Knoten hinzugefügt, aber kein Ergebnis konfiguriert hatten. Instanzen, die zuvor mit 400s fehlschlugen und nicht in der Lage waren, wieder aufzunehmen Detektion Ein Kunde meldete das Problem an Maestro Engineering SME, der es intern mit dem Team ansprach. Das Maestro-Team untersuchte diesen Fehler und beobachtete eine zunehmende Anzahl von Fehlern für USI und einige andere Mieter über Protokolle, was dazu führte, dass sie das Action Center-Team engagierten. ## Antwort Das Maestro-Team erhielt einen Bericht über das Problem vom Kunden per E-Mail, und sie führten eine erste Untersuchung durch und identifizierten eine mögliche Regression, woraufhin das Action Center SME engagiert wurde, das Problem in niedrigeren Umgebungen reproduziert wurde, ein Rollback der Funktion angewendet und getestet und auf alle betroffenen Regionen ausgerollt wurde. Es wurde gelöst, indem alle Instanzen intern wiederholt und wieder aufgenommen wurden. ## Follow-up 1. Hinzufügen der Validierung für dieses Szenario auf allen dienstübergreifenden Codebasisoberflächen, um eine menschliche Überprüfung zu gewährleisten 2. Hinzufügen erforderlicher Überwachungs- und Integrationstests, um dieses Problem schneller zu erkennen

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 7. Oktober 2026 um 17:37 UTCinvestigating

   Wir untersuchen Berichte über intermittierende Langsamkeit und Fehler, die eine Teilmenge von Organisationen in der Region Automation Cloud im Osten der USA betreffen. Betroffene Benutzer sehen möglicherweise, dass Seiten in der Orchestrator-Benutzeroberfläche nicht geladen werden (z. B. die Jobs-Seite, die "Ein Fehler ist aufgetreten" zurückgibt), und Roboteroperationen wie Warteschlangentransaktionen und Sitzungsstarts können zeitweise ausfallen. Wir werden ein Update bereitstellen, sobald weitere Informationen verfügbar sind.

2. 7. Oktober 2026 um 18:13 UTCmonitoring

   Wir haben eine Kapazitätserhöhung für die betroffene Datenbankinfrastruktur in der Region Ost-USA vorgenommen und Fehlerquoten und Latenz auf ein normales Niveau zurückgeführt. Wir werden ein Update bereitstellen, sobald weitere Informationen verfügbar sind.

3. 7. Oktober 2026 um 19:06 UTCresolved

   Wir haben das Problem in der Region Ost-USA, und Fehlerquoten und Latenz sind wieder auf ein normales Niveau zurückgekehrt.

4. 14. Oktober 2026 um 11:42 UTCpostmortem

   ## Customer Impact Zwischen ca. 13:00 UTC und 18:15 UTC am 7. Oktober 2026 erlebten Kunden in der US-Region intermittierende Fehler und langsame Reaktionen im Orchestrator. Betroffene Benutzer haben möglicherweise gesehen, dass Orchestrator-Seiten nicht geladen wurden, z. B. die Jobs-Seite, die "Ein Fehler ist aufgetreten" zurückgibt, und Roboteroperationen wie Warteschlangentransaktionen und Sitzungsstarts haben möglicherweise zeitweise abgelaufen. Andere UiPath-Dienste, die von Orchestrator abhängig sind, haben in diesem Zeitraum möglicherweise auch langsamere Antworten oder Fehler gesehen. ## Wurzelursache Mehrere häufig verwendete Orchestrator-Operationen stützten sich jeweils auf eine gemeinsame kurzlebige Ressource innerhalb der Datenbank, einschließlich der Routinestatusprüfung, die jeder laufende Roboter durchführt. Da das Volumen der gleichzeitigen Roboteraktivitäten in dieser Region zunahm, begannen Anfragen, sich für den Zugang zu dieser gemeinsamen Ressource in die Warteschlange zu stellen, anstatt ihre Arbeit abzuschließen. Der Effekt war eher selektiv als eine allgemeine Verlangsamung: Die Operationen, die diese Ressource verwendeten, verzögerten sich, während andere normal weiterliefen. Da Prozessor-, Speicher- und Speichernutzung der Datenbank alle innerhalb normaler Bereiche blieben, zeigte die routinemäßige Kapazitätsüberwachung kein Problem. Detektion Unsere automatisierte Überwachung erkannte die Verschlechterung innerhalb von etwa 35 Minuten nach Beginn der Kundeneinwirkung und unsere Ingenieure identifizierten die zugrunde liegenden Streitigkeiten während des Ereignisses. Da dies eher ein Streitproblem als ein Kapazitätsmangel war und alle Kapazitätsindikatoren normal waren, wurde nicht erwartet, dass die zunehmende Datenbankkapazität es lösen würde, und das Team untersuchte Alternativen, bevor es angewendet wurde. Diese Bewertung verzögerte die Minderung. ## Antwort Unser Engineering-Team hat die Kapazität der betroffenen Datenbank erhöht. Reaktionszeiten und Fehlerraten normalisierten sich sofort wieder, und wir überwachten weiter, um zu bestätigen, dass der Dienst stabil war, bevor wir den Vorfall schlossen. * 13:00 : Fehlerraten und Reaktionszeiten beginnen für Kunden in der US-Region zu steigen. * 13:36 : Automatisiertes Monitoring erkennt die Verschlechterung und benachrichtigt das On-Call-Engineering-Team. 13:36 – 17:29 : Ingenieure untersuchen. Alle Standard-Datenbankkapazitätsindikatoren - Prozessor, Speicher und Speicher - bleiben durchgehend in normalen Bereichen, so dass die Ursache aus der Routineüberwachung nicht ersichtlich ist. * 17:29 : Ein formeller Vorfall wird erklärt und das gesamte Reaktionsteam wird engagiert. 17:38 Eine öffentliche Bekanntmachung wird veröffentlicht auf [UiPath Status](http://status.uipath.com/) \(Untersuchung\). * 17:31 – 17:43 : Zusätzliche Datenbankkapazität wird für die betroffene Region bereitgestellt. * 18:00 : Fehlerraten, Antwortzeiten und Anforderungslatenz kehren auf ein normales Niveau zurück. * 18:11 : Die Statusseite wird auf Monitoring & Customer Impact Ends aktualisiert. * 19:06 : Der Vorfall wird geschlossen, nachdem die kontinuierliche Überwachung bestätigt, dass der Dienst stabil ist. ## Follow-up Um zu verhindern, dass sich dies wiederholt, sind wir: * Ändern der betroffenen Operationen, damit sie nicht mehr von der gemeinsam genutzten Ressource abhängen. Dies wurde auf alle betroffenen Systeme ausgerollt und hat den Zustand, der den Vorfall verursacht hat, erheblich reduziert. * Ermöglicht eine detaillierte Datenbanküberwachung auf diesen Systemen, so dass diese Klasse von Streitigkeiten sichtbar ist, während sie stattfindet und nicht danach. * Verbesserung unserer Alarmierung, so dass eine echte Degradation dieser Art deutlich von routinemäßigen, selbstkorrigierenden Variationen zu unterscheiden ist und schneller eskaliert.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 6. Oktober 2026 um 17:50 UTCinvestigating

   Wir untersuchen Berichte über einen Ausfall, der sich auf [beeinflusste Funktionalität oder Benutzersymptom] für Orchestrator in Europa auswirkt. Auswirkungen: Benutzer können mit Verzögerungen bei der Aufnahme von Roboterprotokollen und / oder der Suche / Anzeige der Protokolle rechnen. Es gehen keine Protokolle verloren. Nächstes Update: Unsere Teams arbeiten daran, die Ursache und den Umfang zu verstehen und werden Updates nach Verfügbarkeit teilen.

2. 6. Oktober 2026 um 18:28 UTCidentified

   Wir haben die Ursache für einen Ausfall identifiziert, der sich auf die Aufnahme von Roboterprotokollen für Orchestrator in Europa auswirkt. Auswirkungen: Benutzer können mit Verzögerungen bei der Aufnahme von Roboterprotokollen und / oder der Suche / Anzeige der Protokolle rechnen. Es gehen keine Protokolle verloren. Nächstes Update: Unsere Teams arbeiten daran, die Ursache und den Umfang zu verstehen und werden Updates nach Verfügbarkeit teilen.

3. 6. Oktober 2026 um 18:43 UTCmonitoring

   Wir haben das Problem der Aufnahme von Roboterprotokollen für Orchestrator in Europa gemildert. Auswirkungen: Benutzer können mit Verzögerungen bei der Aufnahme von Roboterprotokollen und / oder der Suche / Anzeige der Protokolle rechnen. Es gehen keine Protokolle verloren. Nächstes Update: Unsere Teams arbeiten daran, die Ursache und den Umfang zu verstehen und werden Updates nach Verfügbarkeit teilen.

4. 6. Oktober 2026 um 18:44 UTCresolved

   Wir haben das Problem der Aufnahme von Roboterprotokollen für Orchestrator in Europa gemildert. Auswirkungen: Benutzer können mit Verzögerungen bei der Aufnahme von Roboterprotokollen und / oder der Suche / Anzeige der Protokolle rechnen. Es gehen keine Protokolle verloren. Nächstes Update: Unsere Teams arbeiten daran, die Ursache und den Umfang zu verstehen und werden Updates nach Verfügbarkeit teilen.

5. 7. Oktober 2026 um 11:08 UTCpostmortem

   ## Customer Impact Zwischen ca. 15:45 UTC und 18:45 UTC konnten Kunden, die in den Regionen Europa, Australien und Japan gehostet wurden, die jüngsten Roboterprotokolle im Orchestrator nicht sehen. Logs, die während des Impact-Fensters geschrieben wurden, erschienen nicht in den Jobs- und Logs-Ansichten oder über die Robot Logs-API, und Logs, die an diesem Tag älter als etwa 03:00 UTC waren, waren nur zeitweise verfügbar. Das Aufprallfenster unterschied sich je nach Region: - Australien: ca. 15:45 UTC bis 18:35 UTC - Europa: ca. 16:35 UTC bis 18:00 UTC - Japan: ca. 16:45 UTC bis 18:30 UTC Auftragsausführung, Warteschlangen, Trigger und alle anderen Orchestrator-Funktionalitäten waren nicht betroffen. Es gingen keine Roboterprotokolle verloren. Die während des Aufprallfensters erzeugten Protokolle wurden weiterhin gesammelt und wurden wieder sichtbar, sobald das Problem gemindert wurde. ## Wurzelursache Wir haben ein geplantes Upgrade des Elasticsearch-Dienstes durchgeführt, der Orchestrator-Roboterprotokolle speichert. Das Upgrade verwendet einen blau-grünen Ansatz: Ein neuer Cluster wird neben dem bestehenden erstellt, die Daten werden aus einem Backup in ihn wiederhergestellt, die Pipeline, die neue Protokolle aufnimmt, wird darauf gestartet und erst dann wird der Datenverkehr umgeschaltet. In den betroffenen Regionen wurde der Verkehrsschalter vom Ingenieur genehmigt, der das Upgrade durchführte, bevor die Datenwiederherstellung und der Einnahmeaufholvorgang abgeschlossen waren, was eine Abweichung von unserem Upgrade-Verfahren darstellt. Das war ein menschlicher Fehler. Infolgedessen las Orchestrator Roboterprotokolle aus einem Cluster, die noch keine aktuellen Daten enthielten, während neue Protokolle weiterhin gesammelt wurden, aber noch nicht auf den Cluster-Anfragen indiziert wurden. Der Fehler wurde nicht erkannt, da unsere Bereitstellungstools darauf angewiesen sind, dass der Betreiber die Vollständigkeit der Daten überprüft und die Reihenfolge zwischen der Datenwiederherstellung und dem Verkehrsschalter nicht durchgesetzt wird. Detektion Unser synthetisches Monitoring, das kontinuierlich Testaufträge durchführt und überprüft, ob ihre Protokolle zurückgegeben werden, erkannte fehlende Protokolle in den betroffenen Regionen und erhöhte Warnungen. Unser Engineering-Team korrelierte die Warnungen mit dem laufenden Upgrade, erklärte einen Vorfall und veröffentlichte eine Statusseitenbenachrichtigung. ## Antwort Unser Engineering-Team hat den Datenverkehr auf die vorherigen Elasticsearch-Cluster in allen drei Regionen zurückgeführt, wodurch der Zugriff auf alle Roboterprotokolle, einschließlich derjenigen, die während des Aufprallfensters erzeugt wurden, sofort wiederhergestellt wurde. Wir bestätigten die Genesung durch synthetische Überwachung in jeder betroffenen Region und setzten die Überwachung fort, bevor der Vorfall um ca. 18:45 UTC aufgelöst wurde. Das Upgrade der neuen Cluster setzt sich im Hintergrund fort. Der Datenverkehr wird erst dann zu ihnen verschoben, wenn die Datenwiederherstellung abgeschlossen ist und die Aufnahme bestätigt wurde. ## Follow-up Um zu verhindern, dass sich dies wiederholt, sind wir: - Ändern der Deployment-Pipeline, so dass der Verkehrsschalter nicht ausgeführt werden kann, bis die Datenwiederherstellung und die Protokollaufnahme im neuen Cluster als vollständig verifiziert sind. Hinzufügen eines automatisierten Rollback-Schritts zur Pipeline, so dass der Datenverkehr innerhalb von Minuten zum vorherigen Cluster zurückgegeben werden kann, wenn ein Problem nach einem Wechsel erkannt wird.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 6. Oktober 2026 um 12:38 UTCidentified

   Wir beobachten eine verschlechterte Leistung für Dienstleistungen in den VAE

2. 6. Oktober 2026 um 12:43 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

3. 6. Oktober 2026 um 14:01 UTCidentified

   Wir haben das Problem als ein Netzwerk-Routing-Problem mit einem Drittanbieter identifiziert, das die Konnektivität für unsere in den VAE gehosteten Dienste beeinflusst. Wir arbeiten mit unserem Upstream-Anbieter an der Lösung und werden den Fortschritt hier aktualisieren.

4. 6. Oktober 2026 um 14:22 UTCidentified

   Wir arbeiten weiter an einer Lösung für dieses Problem.

5. 6. Oktober 2026 um 14:51 UTCmonitoring

   Wir überwachen die Konnektivität und werden diese Seite aktualisieren, sobald die Stabilität bestätigt ist.

6. 6. Oktober 2026 um 15:09 UTCmonitoring

   Wir werden weiterhin auf weitere Probleme achten.

7. 6. Oktober 2026 um 17:09 UTCresolved

   Der Vorfall wurde behoben.

8. 21. Oktober 2026 um 05:36 UTCpostmortem

   ## Customer Impact Zwischen 12:38 Uhr UTC und 14:51 Uhr UTC erlebte eine Untergruppe von Kunden in der Region der Vereinigten Arabischen Emirate Ausfälle beim Zugriff auf UiPath-Cloud-Dienste. Der Vorfall dauerte ca. 2 Stunden und 13 Minuten. Betroffene Dienste beinhalteten den Zugang zu **cloud.uipath.com**, **account.uipath.com** Dienstleistungen, die in den VAE gehostet werden. Kunden haben möglicherweise Timeouts, fehlgeschlagene Authentifizierung, Reset-Verbindungen oder Serverfehler festgestellt. ## Wurzelursache Die Hauptursache war ein Fehler im regionalen Netzwerk-Routing bei einem Drittanbieter von Infrastruktur. Eine Untergruppe von ausgehenden Netzwerkpfaden aus der UAN-Region zu bestimmten externen Netzwerken - einschließlich des Content Delivery Networks, das **cloud.uipath.com** und **account.uipath.com** bedient - hat den Datenverkehr eingestellt. Neue Outbound-Verbindungsversuche von betroffenen Diensten erhielten keine Antworten, was dazu führte, dass Anfragen zu Timeout führten. Unser Engineering-Team schloss UiPath-Servicekonfiguration, Richtlinien auf Anwendungsebene und Outbound-Verbindungskapazität als Ursachen aus. Der Infrastrukturanbieter bestätigte ein bekanntes Problem, das mehrere Kunden auf demselben Netzwerkpfad betrifft. Detektion Das Problem wurde durch automatisierte Überwachung erkannt. Etwa um 12:40 Uhr UTC - etwa zwei Minuten nach Beginn des Fehlers - bestätigte die Untersuchung, dass neue Verbindungen von den betroffenen UAN-Regionsdiensten zu den wichtigsten UiPath-Endpunkten fehlschlugen. ## Antwort Um 13:20 Uhr UTC bestätigte unser Ingenieurteam, dass der Fehler auf bestimmte ausgehende Netzwerkpfade beschränkt war, während andere Ziele erreichbar blieben. Die Validierung schloss UiPath-seitige Routingänderungen, Änderungen der Inhaltsbereitstellungskonfiguration, Richtlinien auf Anwendungsebene und Probleme mit der Outbound-Verbindungskapazität aus. Ein hochgradiger Supportfall wurde mit dem Drittanbieter von Infrastruktur eröffnet. Um 13:50 Uhr UTC erkannte der Anbieter ein bekanntes Problem an, das mehrere Kunden betraf. Unser Team überwachte weiterhin die Wiederherstellung der betroffenen Netzwerkpfade und überprüfte den Servicezustand, wenn der Datenverkehr zurückkehrte. Um 14:51 Uhr UTC bestätigten die Recovery-Checks, dass der UiPath-Verkehr über die betroffenen Content-Delivery-Pfade auf ein normales Niveau zurückgekehrt war. Automatisierte Gesundheitschecks und Servicemetriken bestätigten die Wiederherstellung, und Services in UAN waren betriebsbereit. ## Follow-up 1. Wir verfolgen die bestätigten Korrekturmaßnahmen des Infrastrukturanbieters und die Ursachenanalyse für den regionalen Routingfehler. 2. Wir prüfen Outbound-Service-Abhängigkeiten in der betroffenen Region, um die Widerstandsfähigkeit gegen ähnliche Netzwerkunterbrechungen von Drittanbietern zu stärken.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 2. Oktober 2026 um 16:23 UTCinvestigating

   Seit etwa 15:05 UTC können einige Kunden in der US-Region sehen, dass Jobs, die mit Cloud-Robotern ausgeführt werden, länger als üblich dauern, um zu starten oder im ausstehenden Zustand zu bleiben. Jobs an eigenen Robotern sind nicht betroffen, ebenso wenig wie andere Regionen. Wir haben die wahrscheinliche Ursache gefunden und arbeiten daran, die normale Auftragsverarbeitung wiederherzustellen. Jobs, die bereits in der Warteschlange stehen, gehen nicht verloren und werden bearbeitet, sobald das Problem gelöst ist. Wir werden innerhalb von 60 Minuten ein weiteres Update veröffentlichen.

2. 2. Oktober 2026 um 16:34 UTCmonitoring

   Wir haben einen Fix für das Problem angewendet, das Jobs bei Cloud Robots in der US-Region verzögert hat, und Jobs beginnen wieder normal. Verspätete Jobs werden jetzt bearbeitet. Wir überwachen, um sicherzustellen, dass der Dienst stabil bleibt und werden innerhalb von 60 Minuten ein weiteres Update veröffentlichen.

3. 2. Oktober 2026 um 16:51 UTCmonitoring

   Nach weiteren Arbeiten an dem Thema beginnen die Jobs bei Cloud Robots in der US-Region nun normal. Jobs, die sich früher verzögert haben, werden bearbeitet. Wir überwachen den Service weiterhin und werden ein weiteres Update veröffentlichen, sobald das Problem behoben ist.

4. 2. Oktober 2026 um 17:03 UTCresolved

   Dieses Problem ist gelöst. Zwischen 15:05 und 16:39 UTC waren Jobs bei Cloud Robots in der US-Region langsam oder blieben im ausstehenden Zustand. Jobs beginnen seit 16:39 UTC normal, und Jobs, die sich in dieser Zeit verzögert haben, wurden jetzt bearbeitet. Wir entschuldigen uns für die Störung.

5. 14. Oktober 2026 um 14:20 UTCpostmortem

   ## Customer Impact Von 15:00 bis 16:38 UTC am 2026-10-02 dauerte der Start von Cloud Robots-Jobs in der US-Region länger als üblich, bis zu 22 Minuten auf dem Höhepunkt um 16:20 UTC. Orchestrator blieb verfügbar, kein Job ging verloren, keine andere Region war betroffen. Eine kleine Anzahl von Kunden erhielt einen temporären Limitfehler bei neuen Einreichungen, während ihre früheren Jobs warteten. Detektion Automatisierte Alarme feuerten um 15:07 UTC, sieben Minuten nach Beginn des Aufpralls. Die Überprüfungen in der US-Region scheiterten ab etwa 15:32 UTC und die Reaktion auf den Vorfall begann. ## Wurzelursache Um 14:55 UTC begann der Workflow eines Kunden, Jobs mit etwa dem 20-fachen seiner normalen Rate einzureichen. Der Dienst, der Jobs zulässt, behält eine Anzahl pro Kunde in der Datenbank und aktualisiert sie unter einer Datenbanksperre für jeden Jobstart und -ende. Bei diesem Tempo wuchs die Sperrwarteschlange für den Kundenrekord, bis die Updates ausgingen. Die wartenden Updates besetzten den gemeinsamen Pool von Arbeitern, der Jobs für alle Kunden in der Region startet, so dass die Jobs jedes Kunden hinter ihnen warteten. Der Mechanismus, der die Last eines Kunden isolieren sollte, wurde zum Engpass. ## Antwort Das Team identifizierte den überlasteten Zugangspfad und die Arbeitsbelastung dahinter. Eine erste Konfigurationsänderung um 15:46 UTC zielte auf die falsche Aufzeichnung und hatte keine Wirkung. Die korrekte Änderung um 16:10 UTC befreite den Auftragstyp des Kunden von der Datenbanksperre und trat um etwa 16:20 UTC in Kraft. Die Startzeiten sanken von etwa 13 Sekunden auf unter eine Sekunde und der Auftragsbestand von etwa 5200 Jobs wurde in 18 Minuten aufgebraucht. Jobstarts waren um 16:38 UTC normal. Der Trigger des Kunden wurde mit dem Kunden um ca. 16:40 UTC abgeschaltet. ## Follow-up Die datenbankgebundene Ratenbegrenzung wird durch einen In-Memory-Mechanismus zur Begrenzung der Hochleistungsrate ersetzt, so dass die Last eines Kunden Jobstarts für andere nicht blockieren kann. Der Wechsel ist abgeschlossen, wird in der Vorproduktion bei gleicher Last getestet und ausgerollt.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 2. Oktober 2026 um 00:13 UTCinvestigating

   Wir untersuchen derzeit einen Ausfall des Insights-Portals in der Region der VAE. Benutzer in dieser Region können möglicherweise nicht auf das Portal zugreifen oder es kommt zu fehlgeschlagenen Seitenlasten. Unser Team arbeitet aktiv daran, die Ursache zu identifizieren und den Service wiederherzustellen. Wir werden ein weiteres Update bereitstellen, sobald wir weitere Informationen haben.

2. 2. Oktober 2026 um 00:36 UTCidentified

   Wir haben einen Minderungspfad identifiziert und beginnen mit einem Rollback in der Region der VAE. Benutzer können weiterhin intermittierende Zugriffsprobleme mit dem Insights-Portal haben, während diese Arbeiten im Gange sind. Wir werden ein weiteres Update bereitstellen, sobald das Rollback abgeschlossen ist.

3. 2. Oktober 2026 um 00:41 UTCmonitoring

   Das Insights-Portal in der Region der VAE wird nun nach unserem Rollback erfolgreich geladen. Wir überwachen den Service weiterhin, um die Stabilität zu bestätigen, und werden ein endgültiges Update bereitstellen, sobald wir zuversichtlich sind, dass das Problem vollständig gelöst ist.

4. 2. Oktober 2026 um 00:51 UTCresolved

   Das Insights-Portal in der Region der VAE funktioniert nun nach dem Rollback normal. Wir haben die Schlüsselportalfunktionalität validiert und bestätigt, dass der Dienst gesund bleibt. Dieser Vorfall ist nun gelöst.

5. 5. Oktober 2026 um 22:58 UTCpostmortem

   ## Customer Impact Am 1. Oktober 2026** war der Dienst UiPath**Insights** in der Region **VAE** nicht verfügbar. Von ca. **23:40 UTC am 1. Oktober bis 00:39 UTC am 2. Oktober ** konnten Benutzer Insights-Dashboards nicht laden: Anfragen scheiterten nach ca. 10 Sekunden mit einem Fehler. Anfragen zur Bereitstellung von Insights für neue Mieter in der Region scheiterten ebenfalls. Die Störung dauerte ca. **59 Minuten **. Andere UiPath-Dienste in der Region der VAE und Insights in allen anderen Regionen waren nicht betroffen. Es gingen keine Kundendaten verloren. ## Wurzelursache Der Ausfall wurde durch eine ** Konfigurationsänderung** verursacht, die in einem geplanten Insights-Release ausgeliefert wurde. Die Änderung erhöhte die **minimale TLS \(Transport Layer Security\)-Version** auf den Insights-Anwendungsendpunkten in der Region der Vereinigten Arabischen Emirate von TLS 1.2 auf **TLS 1.3** als Teil einer Sicherheitsverhärtung. Das UiPath-Gateway, das den Kundenverkehr zu Insights weiterleitet, verbindet sich mit diesen Endpunkten über TLS 1.2. Sobald die Endpunkte TLS 1.2 nicht mehr akzeptierten, konnte das Gateway keine sichere Verbindung mehr zu ihnen öffnen. Kundenanfragen wurden zeitversetzt und Fehler zurückgegeben, obwohl die Insights-Anwendung selbst gesund blieb. Die Änderung galt nur für die Region der VAE, weshalb keine andere Region betroffen war. Detektion Das Problem wurde von der automatisierten synthetischen Überwachung von **UiPath erkannt, die die Verfügbarkeit von Insights von mehreren Standorten aus kontinuierlich testet. Der erste fehlgeschlagene Gesundheitscheck wurde um 23:40 UTC aufgezeichnet. Automatisierte Warnungen innerhalb von Minuten ausgelöst, und das On-Call-Engineering-Team begann die Untersuchung. ## Antwort Das Ingenieurteam bestätigte, dass der Ausfall nur Insights in der Region der VAE betraf. Die Anwendung lief normal, aber kein Kundenverkehr erreichte sie. Das Team verfolgte den Fehler auf den sicheren Verbindungsschritt zwischen dem Gateway und Insights und verknüpfte ihn mit der TLS-Einstellung, die durch das Release angewendet wurde. Um ca. **00:38 UTC** stellte das Team die vorherige minimale TLS-Version \(TLS 1.2\) auf den betroffenen Endpunkten wieder her. Synthetische Gesundheitschecks begannen sofort zu bestehen, und bis ** 00: 41 UTC ** waren alle Insights-Checks in der Region der VAE gesund. Das Team überwachte weiter, um die volle Stabilität zu bestätigen. ## Follow-up Um ähnliche Vorfälle in Zukunft zu verhindern, unternehmen wir folgende Schritte: * ** Entfernen Sie die TLS-Änderung aus dem Release**, so dass zukünftige Bereitstellungen sie nicht erneut anwenden, bis das Gateway TLS 1.3 Ende an Ende unterstützt. * **Validieren Sie Verbindungssicherheitsänderungen gegenüber dem Gateway** in einer Vorproduktionsumgebung, bevor sie auf die Produktion angewendet werden.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 1. Oktober 2026 um 18:57 UTCinvestigating

   Ab dem 1. Oktober um ca. 13:30 Uhr UTC begannen einige Agenten, einschließlich Low-Code und codierte Agenten, Fehler in allen Regionen zu erleben, wenn sie Gemini-3.1-pro-Preview und gpt-4o-2024-05-13 verwendeten. Diese Modelle können auch für die Auswahl während des Agentendesigns nicht verfügbar sein. Wir untersuchen und arbeiten aktiv an einem Fix.

2. 1. Oktober 2026 um 19:05 UTCidentified

   Wir haben das Problem identifiziert und stellen einen Fix bereit. Agenten, die die betroffenen Modelle verwenden, können weiterhin Ausfälle erleiden, und die Modelle stehen möglicherweise während des Agentendesigns nicht zur Auswahl zur Verfügung, während die Bereitstellung abgeschlossen ist.

3. 1. Oktober 2026 um 19:46 UTCresolved

   Wir haben die Änderung, die dieses Problem verursacht hat, rückgängig gemacht und bestätigt, dass die betroffenen Modelle wieder verfügbar sind. Einige Agenten können weiterhin intermittierende Fehler auftreten, während Instanzen sich aktualisieren. Wir überwachen weiterhin das Agentendesign und die Ausführung für gemini-3.1-pro-preview und gpt-4o-2024-05-13.

4. 7. Oktober 2026 um 10:15 UTCpostmortem

   ## Customer Impact Am 1. Oktober 2026, von 14:31 bis 19:40 UTC, konnten Agenten, die mit einigen großen Sprachmodellen wie Gemini 3.1 Pro Preview und GPT-4o (2024-05-13) konfiguriert waren, nicht in allen Regionen starten, wobei der Fehler lautete, dass das Modell nicht verfügbar ist. Die gleichen Modelle fehlten in der Modellliste beim Entwerfen von Agenten. Agenten, die andere Modelle verwendeten, waren nicht betroffen. ## Wurzelursache Ein Feature-Flag wurde umgedreht, was dazu führte, dass der Agents-Dienst mit dem Senden eines Operationscodes an Modellentdeckungsanforderungen begann. Dies führte dazu, dass die Liste der Modelle dazu diente, diese spezifische Operation zu sein, im Gegensatz zur Basis-Agenten-Modellliste. Die Liste der Pro-Operation-Modelle wurde ursprünglich aus der Bring Your Own Model (BYOM)-Konfiguration von überschreibbaren Modellen erstellt, die für Agenten nicht mit der vollständigen Liste der unterstützten Modelle im Agentendienst übereinstimmten. Die interne Revision zeigte, dass dies ein Fehler und keine absichtliche Lücke war. Im Laufe der Zeit wurde diese Lücke nie behoben, und nach dem Flagwechsel würden Agenten, die bereits mit einem der betroffenen Modelle konfiguriert waren, aufgrund ihrer Abwesenheit aus der zurückgegebenen Liste ausfallen. Detektion Ein Kunde meldete das Problem und es wurde um 16:44 UTC an unsere Ingenieure eskaliert. Unsere Überwachung wurde nicht alarmiert, da dieser Fehler normalerweise auf Konfigurationsprobleme auf Organisations- oder Agentenebene hinweist. ## Antwort Ingenieure verfolgten die Fehler der Konfigurationsänderung und kehrten sie um 19:01 UTC zurück. Der Revert trat in den folgenden Minuten in Kraft, und der letzte Fehler trat um 19:40 UTC auf. ## Follow-up 1. Die Modelllisten werden angeglichen, bevor diese Änderung erneut vorgenommen wird. 2. Wir ändern, wie dieser Fehler klassifiziert wird, so dass ein plattformweiter Spike unsere Ingenieure alarmiert.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 1. Oktober 2026 um 18:17 UTCinvestigating

   Ab dem 1. Oktober um ca. 12:00 Uhr UTC können Community-Benutzer in Europa Fehler bei LowCode-Agenten feststellen, die lösungsbasierte lokale Aktions-Apps verwenden. Wir haben bestätigt, dass die Auswirkungen auf Community-Nutzer in Europa begrenzt sind. Wir untersuchen das Problem aktiv, bestimmen das Ausmaß der Ausfälle und arbeiten an einer Lösung.

2. 1. Oktober 2026 um 18:25 UTCidentified

   Wir haben das Problem identifiziert, das zu Ausfällen bei Low-Code-Agenten führt, die lösungsbasierte lokale Aktions-Apps für Community-Benutzer in Europa verwenden. Wir nehmen die bisherigen Änderungen zurück und überwachen die Erholung weiter. Wir werden ein weiteres Update bereitstellen, sobald das Rollback abgeschlossen ist oder wenn wir zusätzliche Informationen teilen müssen.

3. 1. Oktober 2026 um 20:08 UTCresolved

   Wir haben bestätigt, dass das Rollback abgeschlossen ist und das Problem mit Low-Code-Agenten, die lösungsbasierte lokale Aktions-Apps für Community-Benutzer in Europa verwenden, behoben wurde. Die Dienste haben sich erholt, und wir schließen diesen Vorfall ab.

4. 7. Oktober 2026 um 14:28 UTCpostmortem

   ## Customer Impact Am 1. Oktober 2026, von 10:50 bis 19:50 UTC, konnten einige Studio-Web-Benutzer in Europa keine Agenten debuggen, die Orchestrator-Prozesse (RPA, Agenten usw.) oder Action-Apps aus derselben Lösung aufrufen. Der Anruf scheiterte mit einem "nicht gefunden" Fehler. Veröffentlichte Agenten und Produktionsjobs waren nicht betroffen. ## Wurzelursache Ein Studio-Web-Update hat geändert, wie sich Lösungsressourcen während des Debuggens befinden. Es fehlte eine Einstellung, die das vorherige Verhalten beibehält, so dass Debug-Läufe nach den Ressourcen der Lösung im persönlichen Arbeitsbereich des Benutzers anstelle des Debug-Ordners suchten. Detektion Automatisierte End-to-End-Tests alarmierten unsere Ingenieure um 16:43 UTC. Die End-to-End-Testsuite läuft einmal alle 2 Stunden und die Warnung erfolgt nur nach 3 aufeinanderfolgenden Testfehlern. Das Problem wurde auch aus einer Kundenumgebung gemeldet. ## Antwort Nach der Identifizierung der Ursache wurde um 18:00 UTC ein Rollback gestartet und war um 19:50 UTC vollständig in Kraft. Diese Dauer beinhaltete einen Bereitstellungsfehler, der wiederholt werden musste, was 50 Minuten dauerte. Eine korrigierte Version, die die Einstellung enthält, wurde am 2. Oktober um 13:00 Uhr UTC bereitgestellt. ## Follow-up 1. Die Einstellung ist jetzt Teil der Hauptcodezeile, so dass zukünftige Veröffentlichungen sie enthalten. 2. Wir verbessern die Alarme und die End-to-End-Testsuite, um Regressionen früher zu erkennen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 1. Oktober 2026 um 16:32 UTCresolved

   Zwischen 14:23 und 16:04 UTC am 1. Oktober 2026 scheiterten einige Anfragen zum Löschen von Elementen in UiPath Automation Cloud-Diensten in der Region Australien mit "404 Not Found" -Fehlern. Betroffen waren Orchestrator, Document Understanding, AI Center und Data Service. Andere Operationen, wie das Anzeigen, Erstellen und Aktualisieren von Elementen, funktionierten normal. Die Ursache war eine Konfigurationsänderung unseres Request-Routings. Wir haben es zurückgerollt und der Service ist vollständig wiederhergestellt.

2. 7. Oktober 2026 um 10:15 UTCpostmortem

   ## Customer Impact Zwischen dem 1. Oktober 2026 um 14:23 Uhr UTC und 16:04 Uhr UTC kam es zu **404 Not Found**-Fehlern bei einigen UiPath Automation Cloud-Anfragen in der Region Australien. Der Vorfall dauerte 1 Stunde und 41 Minuten. Betroffene Anfragen beinhalteten Löschvorgänge und einige Robot-Verbindungsprüfungen. Betroffen waren Orchestrator, Document Understanding, AI Center und Data Service. Roboterjobs, die Orchestrator genannt wurden, sind möglicherweise fehlgeschlagen, und Kunden müssen möglicherweise alle Roboterjobs erneut ausführen, die während dieses Fensters fehlgeschlagen sind. Alle anderen Operationen waren nicht betroffen. ## Wurzelursache Eine Routing-Konfigurationsänderung wurde auf die Region Australien mit einem unvollständigen Satz unterstützter Operationen aufgrund eines Timeouts in der Release-Pipeline angewendet. Löschvorgänge fehlten in der Konfiguration, so dass diese Anforderungen auf der Routing-Ebene mit **404 Nicht gefunden ** abgelehnt wurden, bevor die zugrunde liegenden Dienste erreicht wurden. Detektion Automatisiertes Ende-zu-Ende-Monitoring erkannte das Problem durch Alarmierung bei Fehlern für die Überprüfung des Document Understanding-Services. Unser Engineering-Team verwendete dann interne Überwachungsdaten, um das breitere Muster von Fehlern in den betroffenen Diensten zu bestätigen. ## Antwort Während der Untersuchung zeigten Überwachungsdaten, dass Anfragen, die durch die Region Australien geleitet wurden, **404 Nicht gefundene ** Fehler zurückgaben, während Anfragen, die durch andere Regionen geleitet wurden, nicht betroffen waren. Die Analyse ergab, dass die Startzeit der Antworterhöhung von **404 Not Found** mit der Zeit korreliert war, zu der die Routing-Konfiguration in Kraft trat. Das Team hat die Routing-Konfiguration auf die vorherige Arbeitsversion zurückgesetzt. Nach dem Rückwärtsgang zeigte die Überwachung, dass die Fehlerzahlen innerhalb von etwa drei Minuten zurückgingen, und der Dienst wurde bis zum 1. Oktober 2026 um 16:04 Uhr UTC vollständig wiederhergestellt. ## Follow-up 1. Verbesserung von Routing Layer Alerts bei 4xx Baseline-Änderungen 2. Teilweise angewandte Routing-Konfigurationen erkennen, bevor sie in Kraft treten

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 1. Oktober 2026 um 13:21 UTCinvestigating

   Unser Team arbeitet aktiv an einem Fix für die verschlechterte Performance, die Orchestrator in der US-Region betrifft. Wir werden Updates teilen, wenn Fortschritte gemacht werden.

2. 1. Oktober 2026 um 14:06 UTCidentified

   Ein Fix wird derzeit für die verschlechterte Leistung von Orchestrator und Action Center in der US-Region eingesetzt. Weitere Updates werden folgen.

3. 1. Oktober 2026 um 14:24 UTCmonitoring

   Es wurde ein Fix für die verschlechterte Leistung von Orchestrator und Action Center in der US-Region implementiert. Unser Team überwacht die Ergebnisse aktiv, um zu bestätigen, dass das Problem vollständig gelöst ist.

4. 1. Oktober 2026 um 17:58 UTCmonitoring

   Es wurde ein Fix für die verschlechterte Leistung von Orchestrator und Action Center in der US-Region implementiert. Wir überwachen weiterhin die Systemleistung und -stabilität, um zu bestätigen, dass das Problem vollständig gelöst ist. Weitere Updates werden bereitgestellt, sobald mehr Informationen verfügbar werden.

5. 1. Oktober 2026 um 19:03 UTCresolved

   Die verschlechterte Leistung von Orchestrator und Action Center in der US-Region wurde behoben. Die Systemleistung ist nach dem implementierten Fix stabil geblieben, und wir werden die Standardüberwachung fortsetzen.

6. 5. Oktober 2026 um 06:40 UTCpostmortem

   ## Customer Impact Zwischen ca. 11:00 UTC und 13:40 UTC am 1. Oktober 2026 beobachteten Kunden in der US-Region langsamere Orchestrator-Reaktionszeiten und intermittierende Timeouts. Roboter brauchten länger, um Jobs zu starten, Warteschlangen zu verarbeiten und Assets zu lesen, und einige dieser Anfragen scheiterten. Andere UiPath-Dienste, die auf Orchestrator angewiesen sind, waren ebenfalls betroffen, während Orchestrator degradiert wurde und möglicherweise langsamere Antworten oder Fehler gesehen haben. ## Wurzelursache Eine Orchestrator-Fix-Bereitstellung beinhaltete eine Änderung der Art und Weise, wie die Rechenkapazität für unsere Dienste reserviert und skaliert wird. Die Änderung sollte unsere Infrastruktur effizienter nutzen, verringerte jedoch die Verarbeitungskapazität, die Orchestrator zur Verfügung stand. In geschäftigen Zeiten hat unsere automatische Skalierung die Kapazität nicht wie erwartet erhöht, so dass der Service nicht mit der Nachfrage Schritt halten konnte. Detektion Unsere interne Überwachung erkannte die Verlangsamung nach dem Update. Unser erster Plan war es, ein korrigiertes Update durch unseren Standard-Release-Prozess zu veröffentlichen, der mehrere Stunden dauert. Als Kundenberichte hereinkamen, eröffneten wir einen Vorfall und gingen zu einer schnelleren Lösung über. ## Antwort Unser Engineering-Team hat die vorherigen Kapazitätseinstellungen direkt auf die betroffenen Dienste angewendet, ohne auf das korrigierte Update zu warten. Die Reaktionszeiten wurden um ca. 13:40 UTC wieder normal und wir überwachten weiter, um zu bestätigen, dass der Service stabil war. ## Follow-up Um zu verhindern, dass sich dies wiederholt, sind wir: - Permanente Wiederherstellung der vorherigen Kapazitätseinstellungen und Überprüfung zukünftiger Kapazitätsänderungen im Vergleich zur Last auf Produktionsebene vor dem Rollout. - Verbesserung der Art und Weise, wie wir die Auswirkungen von Kunden während Degradationen bewerten, sodass sie zu einem früheren Vorfall eskaliert werden. - Schnelleres Zurücksetzen von Kapazitäts- und Konfigurationsänderungen, wenn sie Kunden betreffen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.