Historia awarii Uipath

1. 28 października 2026 10:04 UTCinvestigating

   Prowadzimy dochodzenie w sprawie zwiększonego opóźnienia i opóźnienia w wykonywaniu pracy w ramach serwisu orkiestrującego w regionie Europy. Nasz zespół aktywnie pracuje nad zidentyfikowaniem przyczyny i dostarczy dalsze aktualizacje w miarę dostępności większej ilości informacji.

2. 28 października 2026 10:28 UTCmonitoring

   Kwestia ta została złagodzona, a my monitorujemy służbę w celu zapewnienia stabilności.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 27 października 2026 16:39 UTCresolved

   W dniu 27 października 2026 r., w dniach 14: 35-16: 08 UTC, w regionie europejskim doszło do częściowego przerwania procesu ekstrakcji generacyjnej, klasyfikacji generacyjnej i autowalidacji. Podstawową przyczyną była kwestia łączności z dostawcą pamięci masowej strony trzeciej. Połączenie zostało przywrócone i potwierdziliśmy, że ekstrakcja i klasyfikacja działają normalnie od 16: 08 UTC.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 26 października 2026 14:04 UTCidentified

   Badamy obecnie kwestię wpływającą na dostępność spostrzeżeń i usług automatyki. Nasz zespół aktywnie ocenia sytuację w celu zidentyfikowania przyczyny i określenia niezbędnych kroków w celu przywrócenia normalnych operacji. Dalsze aktualizacje będą dostarczane w miarę dostępności większej ilości informacji.

2. 26 października 2026 15:35 UTCidentified

   Problem z Operacją Automatyczną został rozwiązany. Obecnie czekamy na złagodzenie problemu usługi Insights. Dalsze aktualizacje będą udostępniane w miarę ich dostępności.

3. 26 października 2026 17:09 UTCidentified

   Insights service in Singapore, Japan, Switzerland, Canada, India, UK, Europe, Stany Zjednoczone, Zjednoczone Emiraty Arabskie, Korea Południowa i Australia region jest ustalona i stosujemy fix na innych regionach

4. 26 października 2026 18:27 UTCresolved

   Sprawa została rozwiązana i wszystkie usługi funkcjonują teraz normalnie.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 27 października 2026 10:13 UTCresolved

   W dniu 26 października 2026 r., między 10: 20 a 17: 30 UTC, Automation Cloud Robots (VM) doświadczyło częściowej przerwy w pracy maszyny. Podczas tego okna działania takie jak uruchamianie, zatrzymywanie lub zabezpieczanie maszyn VM mogły nie zostać zakończone, a zadania zaplanowane na tych maszynach mogły zostać opóźnione lub zablokowane. Przyczyną była błędna konfiguracja praw na podzbiorze podstawowych zasobów infrastruktury. Nasz zespół zidentyfikował problem, poprawił konfigurację i potwierdził, że operacje maszyn działają normalnie od 17: 30 UTC. Przeglądamy sposób wprowadzenia błędnej konfiguracji i dodajemy kontrole, aby zapobiec nawrotom. Nie jest wymagane działanie po twojej stronie. Jeśli nadal widzisz nieudaną lub zablokowaną pracę z tego okna, spróbuj ponownie i skontaktuj się ze wsparciem, jeśli problem utrzymuje się.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 23 października 2026 21:35 UTCresolved

   Między 20: 42 a 21: 19 UTC w dniu 23 października niektórzy klienci orkiestratorów w Europie dostrzegli powolne reakcje i okresowe błędy. Obejmowało to rozmowy robotów, aby uzyskać aktywa, kolejki procesów i zgłosić status zadania. Niektóre prace bez opieki mogły się w tym czasie nie udać. Przyczyną był nagły wzrost obciążenia, który osiągnął limit zasobów bazy danych. Dodaliśmy pojemność bazy danych, a wydajność wróciła do normy od 21: 19 UTC. Klienci, których praca nie powiodła się w tym oknie, mogą potrzebować ich ponownie uruchomić.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 22 października 2026 12:59 UTCinvestigating

   Zidentyfikowaliśmy problem wpływający na IXP dla klientów w regionie Australii. Od 10: 24 UTC, wnioski, które korzystają z modelu Gemini 2.5 Flash nie są w regionie. Inne modele nie są naruszone. Dane klientów są nadal przetwarzane tylko w Australii. Współpracujemy z Google, aby przywrócić usługę

2. 22 października 2026 14:19 UTCmonitoring

   Zastosowano rozwiązanie i służba wraca do zdrowia. Monitorujemy system, aby zapewnić pełną regenerację. Dalsze aktualizacje zostaną wkrótce udostępnione

3. 22 października 2026 14:33 UTCinvestigating

   Po początkowej windykacji usługa uległa ponownemu pogorszeniu. Prowadzimy śledztwo i pracujemy nad rezolucją. Dostarczymy dalsze aktualizacje w miarę ich dostępności.

4. 22 października 2026 15:42 UTCinvestigating

   Skontaktowaliśmy się z Google Support i rozpoczęli śledztwo. Będziemy monitorować i udostępniać aktualizacje.

5. 22 października 2026 17:56 UTCmonitoring

   Obserwujemy poprawę ruchu Gemini 2.5 Flash. Monitorujemy możliwe rozwiązanie z Google.

6. 22 października 2026 21:02 UTCresolved

   Kwestia została rozwiązana przez Google.

7. 26 października 2026 03:20 UTCpostmortem

   # # Wpływ na klienta Między 22 października 2026 o 10: 24 rano UTC i 22 października 2026 o 18: 04 UTC, żądania przetwarzania dokumentów, które używały Gemini 2.5 Flash w regionie Australii nie powiodły się z błędami w przepustowości. Uderzenie trwało około 7 godzin i 40 minut. Wpływ na podzbiór klientów wykorzystujący przepływy pracy związane z wydobyciem dokumentów w tym regionie został naruszony. Podczas tymczasowej próby awaryjnej wewnątrz regionu, niektóre wnioski o ekstrakcję odzyskano krótko, ale przypisanie słowo-poziom i wygenerowany tekst strony zostały zdegradowane aż do upadku również zaczął zawodzić. # # Root cause Główną przyczyną było zakłócenie sieci regionalnej po stronie provideru podczas równoczesnej konserwacji. Spowodowało to znaczne zatłoczenie przepustowości w środowisku modelowania dostawcy, co uniemożliwiło systemom oparcia załadowanie danych potrzebnych do obsługi aplikacji Gemini 2.5 Flash i Gemini 3.5 Flash niezawodnie w dotkniętym regionie. # # Detection Problem został wykryty poprzez automatyczne ostrzeżenie, że zidentyfikowane błędy ograniczające rate- na Gemini 2.5 Flash w regionie Australii. Nasz zespół inżynieryjny potwierdził poprzez telemetrię, że wpłynęły na wnioski były nieskuteczne konsekwentnie i rozpoczął koordynację reakcji. # # Response O 13: 40 UTC, skierowaliśmy dotknął Gemini 2.5 Flash ruchu do Gemini 3.5 Flash w tym samym regionie, aby zachować rezydencję danych. Wstępna telemetria nie wykazała żadnych błędów w pojemności po tej zmianie, ale do 14: 10 UTC, Gemini 3.5 Flash również zwracał błędy w przepustowości, więc nie było już realności. O 14: 05 UTC, dostosowaliśmy powiązane ścieżki przetwarzania dokumentów tak przypisywanie i generowanie tekstu konkursu używałoby tego samego zapasu w regionie; korekta zakończona około 14: 09 UTC. Po upadku również nie powiodło się, cofnęliśmy zmianę trasy, a o 16: 28 ruch UTC wrócił na oczekiwaną ścieżkę Gemini 2.5 Flash. O 17: 38, telemetria wykazała poprawę wskaźnika sukcesu Gemini 2.5 Flash. Od 18: 04 UTC dalej, nie zaobserwowano żadnych dalszych błędów zdolności produkcyjnych, a kolejne wnioski się powiodły. # Follow up 1. Ukończenie zastrzeżonej oceny zdolności przepustowej dla danego regionu przy użyciu zaobserwowanych wzorców ruchu 2. Oceniaj zachowanie retry i backup w przetwarzaniu dokumentów klientów w celu zmniejszenia ponownego wzmocnienia podczas awarii zdolności po stronie dostawcy.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 15 października 2026 12:27 UTCinvestigating

   Od około 11: 17 UTC klienci w wielu regionach doświadczyli problemów z UiPath Agents and Solutions Management. Nowe miejsca pracy mogą pozostać w stanie oczekującym, a agenci prowadzący mogą doświadczać opóźnień podczas przetwarzania eskalacji lub oczekiwania na wyniki narzędzi. Badamy tę kwestię i pracujemy nad rezolucją.

2. 15 października 2026 13:04 UTCmonitoring

   Sprawa została złagodzona. Monitorujemy te usługi w poszczególnych regionach, aby zapewnić stabilność i potwierdzić, że praca rozpoczyna się i rozmieszczenie rozwiązań funkcjonuje normalnie.

3. 15 października 2026 13:22 UTCresolved

   Ten incydent został rozwiązany. Między 11: 15 a 12: 45 UTC w dniu 15 października wewnętrzny problem konfiguracji uniemożliwiał dostarczanie niektórych wydarzeń pomiędzy usługami UiPath w wielu regionach. Problem został rozwiązany poprzez cofnięcie zmiany, a nowa działalność jest normalnie przetwarzana. Niektóre prace zainicjowane lub w toku w tym oknie mogą wymagać uwagi: - Agenci: Agenci oczekujący na zadania Centrum Działania lub wyniki narzędzia automatyzacji mogą pozostać zablokowane. Praca rozpoczęta od Orchestratora może również pojawić się zablokowany lub czas. - Maestro: Procesy czekające na zadania użytkowników nie mogły zostać wznowione po zakończeniu zadania. - Aplikacje: Stan pozycji kolejki może być przestarzały, a działania wywołane zakończeniem pozycji kolejki mogą nie być uruchomione. - Autopilot dla Everyone: Rozmowy oczekujące na wyniki automatyzacji mogą pozostać zablokowane. - Document Understanding and Context Grounding: Automations and agents waiting for extraction, validation, or indexying may rest support. - Integration Service: Zdarzenia łączników nie wywołały oczekiwanych procesów lub powiadomień. - Rozwiązania i Studio Web: Instalacje, uninstalle, publikacje, rozmieszczanie i walidacje zainicjowane w tym oknie mogą się nie powiodły lub wygasły. Przeciągnięcie tych operacji może rozwiązać problem. Przepraszamy za zakłócenia i dziękujemy za cierpliwość.

4. 21 października 2026 06:47 UTCpostmortem

   * * Uderzenie klienta * * 15 października 2026 r., od 11: 15 do 12: 50 UTC (około 1 godziny i 35 minut), niektóre wydarzenia wymieniane pomiędzy usługami w chmurze UiPath nie zostały dostarczone. Klienci we wszystkich komercyjnych regionach chmury zostały dotknięte. W tym oknie: - Nowi agenci mogą zostać w oczekiwaniu. Agenci oczekujący na wynik narzędzia, eskalacja człowieka, ekstrakcja dokumentów lub uziemienie kontekstu może nie powrócić. - Agenci konwersacji i Autopilot dla Everyone rozmowy, które rozpoczęły automatyzację mogły nie otrzymać jego wyniku. - instancje procesu Maestro czekające na zadanie użytkownika mogły nie przejść do przodu po zakończeniu zadania, a procesy wywołane zdarzeniami ze złączem Integration Service mogły się nie rozpocząć. - Aplikacje wyświetlające lub reagujące na status pozycji kolejki mogą wyświetlać przestarzałe informacje. - Instalacje rozwiązań, uninstalle, publikacje, i wdrożeń może się nie udać lub czas. - Niektóre zmiany użytkownika, grupy i folderu dokonane w oknie mogły nie zostać rozpowszechnione na wszystkie usługi. Prace rozpoczęte po 12: 50 UTC nie uległy zmianie. Robot wykonuje zadania, kolejki i wyzwalacze obsługiwane wewnątrz Orchestratora działa normalnie. * * Root cause * * Przenosiliśmy dostawę wewnętrznej konfiguracji usług do nowego mechanizmu, zmiany, która nie ma wpływu na klientów. Kiedy zmiana ta została zastosowana do usługi dostarczania zdarzeń, jego konfiguracja nie była wymagana. Bez niego, usługa traktowała kilka integracje produktu jako wyłączone i cicho przestał dostarczać swoje wydarzenia. Ponieważ zmiana dotarła do wszystkich regionów produkcyjnych w tym samym czasie, każdy region został dotknięty. / Wykrywanie Kwestia ta została wykryta o godzinie 11: 51 UTC, około 35 minut po rozpoczęciu uderzenia, podczas monitorowania informowanego o pracy agenta pozostających w oczekiwaniu. Raporty o rozmieszczeniu rozwiązań w czasie, a incydent został ogłoszony o 12: 12 UTC. * * Odpowiedź * * Po pierwszym wykryciu o 11: 51 UTC, zmiana konfiguracji została zidentyfikowana i cofnięcie rozpoczęto o 12: 00 UTC. Wstępny zwrot o 12: 14 UTC nie w pełni przywrócił dostawę. Następnie zespół zatrzymał nowy proces dostarczania konfiguracji i przywrócił poprzednią konfigurację. Dostawa zdarzeń rozpoczęła się o 12: 40 UTC, a pełne odzyskanie we wszystkich regionach zostało potwierdzone o 12: 50 UTC. Tam, gdzie to możliwe, powtórzyliśmy nieodebrane wydarzenia, tak aby wpływ pracy mógł być kontynuowany. * * Follow up * * 1. Nowy proces dostarczania konfiguracji został wstrzymany dla danej usługi i pozostanie wstrzymany aż do prawidłowego wygenerowania konfiguracji. 2. Sprawdzić konfigurację wyprodukowaną przez nowy mechanizm dostawy dla wymaganych wartości przed zastosowaniem jej w dowolnym środowisku. 3. Rozwijać zmiany w konfiguracji dostawy stopniowo w regionach zamiast do wszystkich regionów jednocześnie. 4. Poprawa monitorowania w celu wykrycia w ciągu kilku minut, gdy zdarzenia przestają być dostarczane do integracji produktów, które zwykle je otrzymuje. 5. Popraw naszą zdolność do odzyskiwania i reprodukcji zdarzeń pominiętych podczas zakłóceń.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 15 października 2026 12:03 UTCresolved

   Niektórzy klienci w regionie USA doświadczyli opóźnień w połknięciu robota, ze zwiększoną aktywnością obserwowaną między około 11: 20 i 11: 45 UTC. Problem został rozwiązany, a spożycie logarytmu powróciło do normy. Dziękuję za cierpliwość.

2. 22 października 2026 10:13 UTCpostmortem

   # # Wpływ na klienta Między 15 października 2026 r. o godz. 11: 20 UTC a 15 października 2026 r. o godz. 11: 45 UTC, niektórzy klienci w regionie USA Wschodniego doświadczyli opóźnień w połknięciu robotów w Orchestratorze UiPath. Logi robotów nie były aktualne w tym okresie. Uderzenie trwało około 20 minut. # # Root cause Podczas incydentu, 2 z 13 instancji serwisowych obsługi robot logowania połknięcia stwierdzono brak połączenia z usługi przyjmowania zdarzeń. Tylko prośby do usługi przyjmowania zdarzeń były nieskuteczne i tylko w tych dwóch przypadkach. Spowodowało to, że niektóre prośby o spożycie robotów nie zakończyły się pomyślnie, co spowodowało opóźnienie danych dziennika dla poszkodowanych klientów. Powód, dla którego tylko te dwa przypadki straciły łączność z serwisem przyjmowania zdarzeń, nie został określony w trakcie incydentu. Zespół zobowiązał się do przeglądu po incydencie dzienników z dotkniętych instancji w celu zidentyfikowania przyczyny. Uważamy, że jest to niezgłoszony problem infrastruktury od naszego operatora chmury. # # Detection Kwestia ta została wykryta przez automatyczny wpis około godziny 23: 33 UTC w dniu 15 października 2026 r. i potwierdzona telemetrią wykazującą wyjątki od dwóch dotkniętych przypadków. # # Response Po wykryciu telemetria potwierdziła, że tylko dwa przypadki świadczenia usług powodują wyjątki. Odpowiedzi usunęły te dwa niezdrowe przypadki z serwisu, a przypadki wymiany rozpoczęły się automatycznie. W ciągu około 20 minut od pierwszego wpisu - około godziny 11: 53 UTC - telemetria wskazywała na powrót do zdrowia i przechodziły syntetyczne kontrole monitorowania. Rozważano szersze ponowne uruchomienie wszystkich instancji serwisowych, ale nie wykonano ich, ponieważ zespół uznał, że nie powinny one kontynuować bez wcześniejszego zrozumienia przyczyny. # Follow up 1. Przegląd poincydentalny dzienników z poszkodowanych instancji usługowych ujawnił problem związany z infrastrukturą, a my śledzimy się z dostawcą infrastruktury w chmurze, aby uzyskać więcej szczegółów. 2. Aktualizacja zostanie opublikowana, jeśli dochodzenie przyniesie dalsze ustalenia.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 14 października 2026 07:26 UTCmonitoring

   Począwszy od 6: 50 UTC doświadczyliśmy globalnego braku, który wpłynął na załadunek aplikacji i kodowanych aplikacji wszystkich regionów z wyjątkiem Indii i Wielkiej Brytanii. Przerwy zostały rozwiązane, a usługi są w pełni operacyjne. Wpływ: Brak stałego wpływu na użytkownika.

2. 14 października 2026 07:43 UTCresolved

   Począwszy od 6: 50 UTC doświadczyliśmy globalnego braku, który wpłynął na załadunek aplikacji i kodowanych aplikacji wszystkich regionów z wyjątkiem Indii i Wielkiej Brytanii. Przerwy zostały rozwiązane, a usługi są w pełni operacyjne. Wpływ: Brak stałego wpływu na użytkownika.

3. 23 października 2026 12:08 UTCpostmortem

   # # Wpływ na klienta Między 06: 38 UTC a 07: 21 UTC w dniu 14 października 2026 r. część wniosków do UiPath Apps, Coded Apps i rozwiązań, które od nich zależą, nie powiodła się w jedenastu regionach: Europie, Stanach Zjednoczonych, Wspólnocie, Japonii, Singapurze, Australii, Kanadzie, Korei Południowej, Szwajcarii, Zjednoczonych Emiratach Arabskich i opóźnionym środowisku amerykańskim. Regiony Indii i Zjednoczonego Królestwa nie zostały naruszone. Około 2 procent wniosków nie powiodło się ogólnie, od 0,6 do 5 procent w zależności od regionu. Dotknięci użytkownicy widzieli, że aplikacje nie ładują, żądają błędów serwera lub powolnych odpowiedzi. W regionach, w których trzeba było ponownie uruchomić kapsuły usługowe, aplikacje były nieosiągalne do około ośmiu minut. Czasy odpowiedzi wróciły do normy w każdym regionie o 07: 40 UTC. Większość użytkowników już uruchomionych opublikowanych aplikacji zauważyła niewiele lub nic. Definicje aplikacji są buforowane w przeglądarce przez okres do 24 godzin, dane aplikacji pochodzą z usługi Data Service i Orchestrator zamiast tej bazy danych, a usługa utrzymywana przy użyciu połączeń baz danych, które już miała. Prośby, które nie powiodły się, to te, które potrzebują nowego połączenia z bazą danych: otwarcie projektanta lub listy aplikacji, załadowanie aplikacji, która jeszcze nie została podpisana, pobieranie dokumentów i obrazów przechowywanych w aplikacjach oraz zapisywanie lub publikowanie. # # Root cause O godzinie 06: 38 UTC, podczas gdy dostęp do bazy danych był ustawiany dla nowego regionalnego wdrożenia, hasło użytkownika bazy danych, które korzysta z usługi Apps zostało zmienione. Użytkownik ten jest współdzielony przez grupy baz danych produkcji wszystkich dotkniętych regionów, tak więc zmiana zastosowana do wszystkich z nich jednocześnie. Usługi bieżące nadal posiadały poprzednie hasło i nie mogły już otwierać nowych połączeń baz danych. Regiony Indii i Zjednoczonego Królestwa nie korzystają z tych uprawnień i nie miały na nie wpływu. Zmiana miała na celu stworzenie osobnego użytkownika bazy danych dla nowego regionu. Zamiast tego zmieniono hasło istniejącego użytkownika, które wszystkie regiony dzielą. Nasz proces zmiany uwierzytelniania baz danych nie oddzielał wyraźnie tworzenia nowych punktów zaufania od zmiany istniejącego, nie wymagał też sprawdzenia, ile klastrów i regionów może mieć wpływ na zmianę wiarygodności. W połączeniu z jednym użytkownikiem bazy danych dzielonym między regiony, umożliwiło to zmianę przeznaczoną dla jednego regionu, która spowodowałaby przestoje wielu regionów. # # Detection Nasze wewnętrzne monitorowanie podniosło pierwszy alarm o 06: 41 UTC, trzy minuty po pierwszych niepowodzeniach, i alarmy dla każdego dotkniętego regionu, a następnie o 06: 46 UTC. O 06: 50 UTC inżynier oncall potwierdził, że każdy klaster produkcyjny został odrzucony przez swoją bazę danych i rozpoczął proces incydentu. # # Response O 07: 05 UTC poprzednie hasło zostało przywrócone, a błędy uwierzytelniania ustały wszędzie. Większość regionów automatycznie się połączyła. W regionach, które tego nie zrobiły, kapsuły usługowe zostały ponownie uruchomione lub rozłożone: opóźnione USA o 07: 21 UTC i Szwajcarii do 07: 30 UTC. Awarie prośby ustały o 07: 21 UTC, czas reakcji wrócił do punktu wyjścia o 07: 40 UTC, a my kontynuowaliśmy monitorowanie do czasu rozwiązania incydentu o 07: 43 UTC. # Follow up Aby zapobiec temu ponownie, jesteśmy: - Wprowadzenie określonej procedury tworzenia i rotacji uwierzytelniania baz danych, z przeglądem poprzedzającym zmianę, w którym stwierdza się, które klastry i regiony dzielą się kredytodawcami, oraz etapowym uruchomieniem, które jest weryfikowane w jednym regionie, zanim będzie ono stosowane szerzej. - Przejście do oddzielenia, mniej uprzywilejowanych użytkowników baz danych dla każdego regionu, tak aby zmiana w jednym regionie nie mogła mieć wpływu na innego. - Automatyczne zgłaszanie incydentu i wywołanie właścicieli baz danych w przypadku wykrycia tego samego błędu bazy danych w kilku regionach na raz, zamiast polegać na ręcznej eskalacji z indywidualnych regionalnych ostrzeżeń. - Umożliwienie odbierania uaktualnionych danych bez ponownego uruchamiania oraz szybszego podłączenia po awarii uwierzytelniania.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 13 października 2026 14:03 UTCinvestigating

   Obecnie badamy awarię usług UiPath Cloud w wielu regionach. Użytkownicy nie są w stanie uzyskać dostępu do usług świadczonych w regionach dotkniętych kryzysem. Następna aktualizacja: Dodatkowe informacje zostaną udostępnione w miarę ich dostępności.

2. 13 października 2026 14:37 UTCinvestigating

   Nadal badamy tę kwestię.

3. 13 października 2026 14:42 UTCinvestigating

   Wprowadzono rozwiązanie i monitorujemy wyniki. Kwestia została ograniczona do Document Understanding, Computer Vision, Semantic Proxy, Autopilot Studi, IXP. Podzielimy się kolejną aktualizacją po pełnym odzyskaniu usług.

4. 13 października 2026 15:10 UTCinvestigating

   Wprowadzono rozwiązanie i monitorujemy wyniki.

5. 13 października 2026 15:19 UTCresolved

   Ten incydent został rozwiązany po odnowieniu wygasłego certyfikatu SSL, które dotyczyło kilku usług zależnych od ML-, w tym IXP, Document Understanding, Computer Vision, Semantic Proxy i Autopilot dla Deweloperów. Odzyskiwanie usług dokonało się we wszystkich dotkniętych regionach, a zautomatyzowane alarmy zostały skonfigurowane, aby z wyprzedzeniem pomóc w wykryciu wygaśnięcia certyfikatu i zapobiec podobnym zakłóceniom w przyszłości. Dziękuję za cierpliwość i zrozumienie.

6. 26 października 2026 03:17 UTCpostmortem

   # # Uderzenie klienta W dniach 13: 37-14: 40 UTC w dniu 13 października 2026 r. klienci z wielu regionów nie byli w stanie korzystać z dokumentów nieustrukturyzowanych IXP, Górnictwa i Ustaleń Dokumentów Łączności IXP. Komputer Vision i Autopilot dla Deweloperów funkcje, które zależą od tych samych usług uczenia maszyn również nie powiodło. Dotknięci klienci widzieli, że wnioski nie powiodły się z odpowiedziami lub przerwami "500 Wewnętrznych Serwerów", projektów IXP, które nie zostaną otwarte, a działania Computer Vision nie powiodą się w automatyzacji. Służba została przerwana na około godzinę. Nie utracono danych klientów. # # Root Cause # Incydent został spowodowany przeterminowanym certyfikatem bezpieczeństwa wykorzystywanym do ustanowienia bezpiecznych połączeń z tymi usługami. Certyfikat jest odnawiany przez zautomatyzowany proces. Proces ten nie był już pomyślnie wykonywany, a awarie nie spowodowały wpisu, więc zaświadczenie nie zostało zastąpione przed jego wygaśnięciem. Od 13: 37 UTC odrzucono bezpieczne połączenia z tymi usługami. # # Detection Automatyczne monitorowanie zaczęło ostrzegać o błędach i braku ruchu o 13: 40 UTC, a incydent został ogłoszony o 13: 54 UTC. Wygasłe świadectwo zostało zidentyfikowane o godzinie 14: 00 UTC, a pierwsza aktualizacja strony o 14: 03 UTC. Żaden wpis nie ostrzegł, że certyfikat zbliża się do wygaśnięcia, a powtarzające się niepowodzenia automatycznego odnowienia nie zostały zgłoszone do zespołu właściciela, więc problem został wykryty dopiero po dotknięciu klientów. # # Response O 14: 06 UTC zespół potwierdził, że certyfikat wygasł z powodu awarii automatycznego odnowienia. O godzinie 14: 18 UTC wydano nowy instrument kredytowy dla procesu odnowienia. Odnowienie rozpoczęto ręcznie o 14: 19 UTC i zakończono o 14: 33 UTC, a o 14: 37 UTC każdy punkt końcowy zwracający się do klienta został zweryfikowany, aby służyć odnowionemu certyfikatowi. Ruch powrócił do normalnego poziomu o około 14: 40 UTC. Po okresie monitorowania, incydent został rozwiązany o 15: 19 UTC. # Follow-Up Aby zapobiec podobnym incydentom w przyszłości, dokonujemy następujących ulepszeń: - Zawiadomienie o każdym z tych certyfikatów zbliża się do wygaśnięcia. - Informuj zespół właściciela, gdy automatyczna odnowa zawiedzie. - Dodać kontrole, że alarm jak tylko bezpieczne połączenia z tych usług nie. - Wzmocnienie prawa własności do procesu odnawiania certyfikatu i jego uprawnień.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 13 października 2026 10:32 UTCinvestigating

   Badamy sprawę, w której logi robotów nie pojawiają się w Orchestratorze. Pracujemy nad określeniem pełnego zakresu i przyczyny.

2. 13 października 2026 10:57 UTCresolved

   Kwestia ta została rozwiązana. Logi wykonania robota są synchronizowane i są widoczne w Orchestratorze ponownie dla Japan Orchestrator. Dziękuję za cierpliwość.

3. 22 października 2026 13:25 UTCpostmortem

   # # Wpływ na klienta Od około 07: 00 UTC w dniu 9 października 2026 r. do 10: 45 UTC w dniu 13 października 2026 r., około 6% wpisów do dziennika robota dla klientów w regionie Japonii nie pojawiło się w Orchestratorze. Wykonanie zadania i wszystkie inne funkcje Orchestratora nie zostały naruszone. Brakujące wpisy stały się widoczne w Orchestratorze po ustawieniu problemu. # # Root cause Logi robotów umieszczane są w kolejce podzielonej na 32 partycje, a usługa spożywania odczytuje każdą partycję i przechowuje dzienniki dla Orchestratora. 9 października usługa spożywania w regionie Japonii przestała czytać z 2 z 32 partycji bez zgłaszania błędu. Logi na tych partycjach były przechowywane w kolejce, ale nie były przechowywane, więc nie pojawiły się w Orchestratorze. Nasze monitorowanie sprawdziło usługę jako całość, nie każdą partycję, więc problem nie został wykryty automatycznie. # # Detection Kwestia ta została wykryta poprzez raporty klientów. Zgłosiliśmy incydent o 10: 13 UTC 13 października i opublikowaliśmy zgłoszenie o statusie o 10: 32 UTC. # # Response Uruchomiliśmy ponownie usługę spożycia około 10: 41 UTC i wznowiliśmy czytanie wszystkich partycji. Logi przechowywane w kolejce były następnie przetwarzane i stały się widoczne w Orchestratorze. Incydent został rozwiązany o 10: 57 UTC. # Follow up * Dodajemy monitoring, który ostrzega nas, gdy pojedyncza partycja przestaje być odczytywana, więc ten rodzaj problemu jest wykrywany w ciągu kilku minut.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 7 października 2026 21:34 UTCinvestigating

   Badamy raporty o niepowodzeniu tworzenia zadań HITL dla Maestro w USA. Wpływ: Użytkownicy mogą nie być w stanie tworzyć zadań HITL. Następna aktualizacja: Nasze zespoły pracują nad zrozumieniem przyczyny i zakresu i udostępnią aktualizacje w miarę dostępności.

2. 8 października 2026 01:30 UTCidentified

   Zidentyfikowaliśmy przyczynę niewykonania zadania HITL dla Maestro w USA i pracujemy nad złagodzeniem tej kwestii. Wpływ: Użytkownicy mogą nie być w stanie tworzyć zadań HITL. Następna aktualizacja: Nasze zespoły pracują nad złagodzeniem problemu i udostępnią aktualizacje, jak to możliwe.

3. 8 października 2026 03:28 UTCmonitoring

   Routing fix for a exage impacting HITL zadanie tworzenia dla Maestros z HITL zadanie zegary SLA skonfigurowane w USA i pracują nad złagodzeniem problemu. Impact: Użytkownicy mogą nie być w stanie tworzyć zadań HITL w Maestros z skonfigurowanymi licznikami zadań HITL SLA. Następna aktualizacja: Nasze zespoły pracują nad złagodzeniem problemu i udostępnią aktualizacje, jak to możliwe.

4. 8 października 2026 04:29 UTCresolved

   Rozwiązanie problemu wpływające na tworzenie zadań HITL dla Maestro z zadaniami HITL zegary SLA skonfigurowane w USA został w pełni rozwinięty. Stworzenie zadania HITL powróciło do normy.

5. 26 października 2026 03:16 UTCpostmortem

   # # Wpływ na klienta 2026- 10- 05 między 9.30 UTC - 2026- 10- 07 3.30 Klienci UTC, Maestro BPMN i Case przy użyciu węzłów HITL z konfigurowanym Task Timer widzieli awarię ich debug i instancji produkcyjnych na etapie HITL, z 4xx. Zidentyfikowano około 30 takich przypadków wśród klientów w Stanach Zjednoczonych i w Europie, które zostały zablokowane bez żadnych działań. # # Root cause Konfigurowanie zadania SLA wymaga obiektu, w tym kryteriów początkowych i końcowych, czasu SLA, i wynik naruszenia SLA. Klienci skonfigurują to na maestro na węźle HITL. Wynik był błędnie utrzymany nieobowiązkowo na powierzchni projektu, nawet jeśli konfiguracja SLA bez wyniku nie jest trwała i nie ma sensu w biznesie. Zespół Backend Action Center dodał walidację, aby rzucić zły wniosek (400) w przypadku obiektu nie null SLA z brakującym wynikiem. Skończyło się to na wpływaniu na klientów, którzy dodali kryteria Start / End do węzła, ale nie skonfigurowali wyniku. Przypadki, które były wcześniej uruchomione nie powiodło się z 400s, i nie były w stanie wznowić # # Detection Klient zgłosił ten problem do Maestro Engineering SME, który podniósł go wewnętrznie z zespołem. Zespół Maestro badał tę porażkę i zaobserwował coraz większą liczbę niepowodzeń dla USI oraz kilku innych najemców za pośrednictwem dzienników, co doprowadziło ich do zaangażowania zespołu Action Center. # # Response Zespół Maestro otrzymał od klienta raport na ten temat za pośrednictwem poczty e-mail, i przeprowadził wstępne dochodzenie i zidentyfikował potencjalną regresję, po której, Centrum Działania zostało zaangażowane, problem powielony na niższych środowiskach, cofnięcie funkcji zastosowanej i przetestowane, a następnie uruchomiony do wszystkich dotkniętych regionów. Rozwiązano ją, a wszystkie przypadki były wewnętrznie ponownie sprawdzane i wznowione. # Follow up 1. Dodanie walidacji dla tego scenariusza na wszystkich powierzchniach kodebazy krzyżowej w celu zapewnienia ludzkiego przeglądu 2. Dodanie wymaganych testów monitorowania i integracji w celu szybszego wykrycia tego problemu

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 7 października 2026 17:37 UTCinvestigating

   Badamy raporty o przerywanej powolności i błędach wpływających na podzbiór organizacji w regionie Automation Cloud. Dotknięci użytkownicy mogą zobaczyć strony w UI Orchestrator nie wczytać (na przykład strona Jobs zwracająca "Wystąpił błąd"), a operacje robotów, takie jak transakcje kolejki i sesje mogą być przerywane. Dostarczymy aktualizację, jak tylko więcej informacji będzie dostępnych.

2. 7 października 2026 18:13 UTCmonitoring

   Zastosowaliśmy zwiększenie zdolności przepustowej infrastruktury bazy danych w regionie wschodnioamerykańskim, a wskaźniki błędów i opóźnienia wróciły do normalnego poziomu. Dostarczymy aktualizację, jak tylko więcej informacji będzie dostępnych.

3. 7 października 2026 19:06 UTCresolved

   Mamy problem w regionie wschodnioamerykańskim, a wskaźniki błędów i opóźnienia wróciły do normalnego poziomu.

4. 14 października 2026 11:42 UTCpostmortem

   # # Wpływ na klienta Między godziną 13: 00 UTC a 18: 15 UTC w dniu 7 października 2026 r. klienci w regionie USA doświadczyli błędów przerywanych i powolnych reakcji w Orchestratorze. Dotknięci użytkownicy mogli widzieć, jak strony Orchestratora nie ładują się, na przykład strona Jobs zwracająca "Wystąpił błąd", a operacje robotów, takie jak transakcje kolejki i sesje mogą być przerywane. Inne usługi UiPath, które zależą od Orchestratora, mogły również w tym okresie widzieć wolniejsze reakcje lub błędy. # # Root cause Kilka często używanych operacji Orchestratora każdy opierał się na wspólnym zasobu krótkożywym wewnątrz bazy danych, w tym rutynowej kontroli stanu, że każdy robot działa. Wraz ze wzrostem ilości równoległych działań robotów w tym regionie, zamiast kończyć swoją pracę, zaczęły się pojawiać prośby o dostęp do wspólnych zasobów. Efekt był raczej selektywny niż ogólny spowolnienie: operacje, które wykorzystały te zasoby, były opóźnione, podczas gdy inne kontynuowały normalne działanie. Ponieważ procesor, pamięć i wykorzystanie pamięci w bazie danych pozostawały w normalnych zakresach, rutynowe monitorowanie pojemności nie wskazywało na problem. # # Detection Nasz zautomatyzowany monitoring wykrył degradację w ciągu około 35 minut od rozpoczęcia oddziaływania na klienta, a nasi inżynierowie zidentyfikowali spór podczas wydarzenia. Ponieważ był to problem sporny, a nie niedobór mocy produkcyjnych, a wszystkie wskaźniki mocy produkcyjnych były normalne, nie spodziewano się, że zwiększenie mocy w bazie danych go rozwiąże, a zespół zbadał alternatywne rozwiązania przed ich zastosowaniem. Ocenę tę opóźniono. # # Response Nasz zespół inżynieryjny zwiększył pojemność bazy danych. Czas reakcji i poziom błędów natychmiast wróciły do normy, a my kontynuowaliśmy monitorowanie, aby potwierdzić, że usługa była stabilna przed zamknięciem incydentu. * 13: 00: Wskaźnik błędów i czas reakcji zaczynają rosnąć dla klientów w regionie USA. * 13: 36: Automatyczne monitorowanie wykrywa degradację i powiadamia zespół inżynierii on-call. * 13: 36 - 17: 29: Inżynierowie badają. Wszystkie standardowe wskaźniki pojemności bazy danych - procesor, pamięć i przechowywanie - pozostają w normalnych zakresach, więc przyczyna nie jest widoczna z rutynowego monitorowania. * 17: 29: Ogłoszono formalny incydent i zaangażowano cały zespół reagowania. 17: 38 Publiczne zawiadomienie jest publikowane w dniu [UiPath Status] (http: / / status.uipath.com /)\ (Badanie\). * 17: 31 - 17: 43: Dodatkowa pojemność bazy danych jest zapewniona dla dotkniętego regionu. * 18: 00: Wskaźniki błędów, czas reakcji i żądania powrotu do normalnego poziomu. * 18: 11: Strona statusu jest aktualizowana do zakończenia monitorowania i wpływu klienta. * 19: 06: Incydent jest zamknięty po ciągłym monitorowaniu potwierdza, że usługa jest stabilna. # Follow up Aby zapobiec temu ponownie, jesteśmy: * Zmiana operacji dotkniętych, więc nie zależą już od wspólnego zasobu. To zostało wprowadzone do wszystkich systemów dotkniętych i znacznie zmniejszyć stan, który spowodował incydent. * Umożliwienie szczegółowego monitorowania bazy danych na tych systemach, więc ta klasa sporów jest widoczna, podczas gdy dzieje się to raczej niż później. * Poprawa naszego ostrzegania tak, że prawdziwa degradacja tego rodzaju jest wyraźnie odróżnialne od rutynowych, samokorekcji zmienności, i jest eskalated szybciej.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 6 października 2026 17:50 UTCinvestigating

   Badamy doniesienia o braku wpływu [wpływającej funkcjonalności lub objawu użytkownika] na Orchestratora w Europie. Impact: Użytkownicy mogą spodziewać się opóźnień w przyjmowaniu dzienników robotów i / lub wyszukiwaniu / wyświetlaniu dzienników. Nie zgubimy dzienników. Następna aktualizacja: Nasze zespoły pracują nad zrozumieniem przyczyny i zakresu i udostępnią aktualizacje w miarę dostępności.

2. 6 października 2026 18:28 UTCidentified

   Zidentyfikowaliśmy przyczynę przestoju wpływającego na spożycie dzienników robotów dla Orchestratora w Europie. Impact: Użytkownicy mogą spodziewać się opóźnień w przyjmowaniu dzienników robotów i / lub wyszukiwaniu / wyświetlaniu dzienników. Nie zgubimy dzienników. Następna aktualizacja: Nasze zespoły pracują nad zrozumieniem przyczyny i zakresu i udostępnią aktualizacje w miarę dostępności.

3. 6 października 2026 18:43 UTCmonitoring

   Złagodziliśmy problem wpływający na spożycie dzienników robotów dla Orchestratora w Europie. Impact: Użytkownicy mogą spodziewać się opóźnień w przyjmowaniu dzienników robotów i / lub wyszukiwaniu / wyświetlaniu dzienników. Nie zgubimy dzienników. Następna aktualizacja: Nasze zespoły pracują nad zrozumieniem przyczyny i zakresu i udostępnią aktualizacje w miarę dostępności.

4. 6 października 2026 18:44 UTCresolved

   Złagodziliśmy problem wpływający na spożycie dzienników robotów dla Orchestratora w Europie. Impact: Użytkownicy mogą spodziewać się opóźnień w przyjmowaniu dzienników robotów i / lub wyszukiwaniu / wyświetlaniu dzienników. Nie zgubimy dzienników. Następna aktualizacja: Nasze zespoły pracują nad zrozumieniem przyczyny i zakresu i udostępnią aktualizacje w miarę dostępności.

5. 7 października 2026 11:08 UTCpostmortem

   # # Wpływ na klienta W dniach od 15: 45 UTC do 18: 45 UTC klienci w regionach Europy, Australii i Japonii nie byli w stanie zobaczyć ostatnich dzienników robotów w Orchestratorze. Logi napisane w oknie uderzenia nie pojawiły się w widokach Jobs i Logs lub poprzez API Logs Robot, a dzienniki starsze niż około 03: 00 UTC tego dnia były dostępne tylko okresowo. Okno uderzenia różniło się w zależności od regionu: - Australia: około 15: 45 UTC do 18: 35 UTC - Europa: około 16: 35 UTC do 18: 00 UTC - Japonia: około 16: 45 UTC do 18: 30 UTC Wykonanie zadania, kolejki, zapalniki i wszystkie inne funkcje Orchestratora nie zostały naruszone. Nie zaginęły żadne kłody robotów. Po złagodzeniu problemu nadal zbierane były logi powstałe w trakcie badania zderzeniowego i ponownie stały się widoczne. # # Root cause Wykonywaliśmy zaplanowaną aktualizację usługi Elasticsearch, która przechowuje dzienniki robotów Orchestratora. Aktualizacja wykorzystuje podejście niebiesko-zielone: obok istniejącego powstaje nowy klaster, dane są do niego przywracane z kopii zapasowej, rurociąg, który pochłania nowe logi, a dopiero wtedy następuje zmiana ruchu. W dotkniętych regionach przełącznik ruchu został zatwierdzony przez inżyniera prowadzącego modernizację przed przywróceniem danych i zakończeniem przechwytywania, co stanowi odstępstwo od naszej procedury aktualizacji. To był ludzki błąd. W rezultacie, Orchestrator czytał dzienniki robotów z klastra, który jeszcze nie zawiera ostatnich danych, podczas gdy nowe dzienniki były nadal zbierane, ale nie były jeszcze indeksowane na klastrze obsługującym żądania. Błąd ten nie został wykryty, ponieważ nasze narzędzia do wdrażania polegają na weryfikacji kompletności danych przez operatora i nie egzekwują porządku pomiędzy przywróceniem danych a przełącznikiem ruchu. # # Detection Nasze syntetyczne monitorowanie, które stale prowadzi zadania testowe i sprawdza, czy ich logi są zwracane, wykrywa brakujące logi w dotkniętych regionach i podnosi alarmy. Nasz zespół inżynieryjny skorelował alarmy z aktualizacją in- progress, ogłosił incydent i opublikował zgłoszenie na stronie statusu. # # Response Nasz zespół inżynieryjny odwrócił ruch do poprzednich klastrów ElasticSearch we wszystkich trzech regionach, które natychmiast przywróciły dostęp do wszystkich dzienników robotów, w tym do tych produkowanych w oknie uderzenia. Potwierdziliśmy powrót do zdrowia poprzez syntetyczne monitorowanie w każdym dotkniętym regionie i dalsze monitorowanie przed oznaczeniem incydentu rozwiązanego około 18: 45 UTC. Modernizacja nowych klastrów jest kontynuowana w tle. Ruch zostanie przeniesiony do nich dopiero po zakończeniu procesu przywracania danych i potwierdzi się aktualność spożycia. # Follow up Aby zapobiec temu ponownie, jesteśmy: - Zmiana rurociągu wdrożeniowego, tak aby przełącznik ruchu nie mógł być uruchomiony, dopóki dane nie zostaną przywrócone i zarejestrowane w nowym klastrze jako kompletne. - Dodawanie automatycznego kroku wstecz do rurociągu, dzięki czemu ruch może być zwrócony do poprzedniego klastra w ciągu kilku minut, jeśli problem zostanie wykryty po przełączniku.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 6 października 2026 12:38 UTCidentified

   Obserwujemy degradowane wyniki dla usług w ZEA

2. 6 października 2026 12:43 UTCinvestigating

   Obecnie badamy tę kwestię.

3. 6 października 2026 14:01 UTCidentified

   Zidentyfikowaliśmy ten problem jako problem routingu sieci z dostawcą usług trzeciej strony, wpływając na łączność dla naszych usług hostowanych w Zjednoczonych Emiratach Arabskich. Współpracujemy z naszym dostawcą w zakresie restrukturyzacji i uporządkowanej likwidacji i będziemy aktualizować postępy.

4. 6 października 2026 14:22 UTCidentified

   Kontynuujemy prace nad rozwiązaniem tego problemu.

5. 6 października 2026 14:51 UTCmonitoring

   Monitorujemy łączność i uaktualnimy tę stronę po potwierdzeniu stabilności.

6. 6 października 2026 15:09 UTCmonitoring

   Nadal monitorujemy wszelkie dalsze problemy.

7. 6 października 2026 17:09 UTCresolved

   Incydent został rozwiązany.

8. 21 października 2026 05:36 UTCpostmortem

   # # Wpływ na klienta Między 12: 38 PM UTC a 14: 51 PM UTC, podzbiór klientów w regionie ZEA doznał niepowodzeń w dostępie do usług w chmurze UiPath. Incydent trwał około 2 godzin i 13 minut. Usługi dotknięte chorobą obejmowały dostęp do * * cloudd.uipath.com * *, * * account.uipath.com * * Usługi prowadzone w Zjednoczonych Emiratach Arabskich. Klienci mogli napotkać timeout, błędne uwierzytelnianie, zresetowanie połączeń lub błędy serwera. # # Root cause Główną przyczyną była awaria sieci tras regionalnych w trzecim dostawcą infrastruktury. Podzbiór wychodzących ścieżek sieciowych z regionu UAN do konkretnych sieci zewnętrznych - w tym sieci dostarczania treści obsługujących * * cloudd.uipath.com * * i * * account.uipath.com * * - zaprzestał dostarczania ruchu. Nowe próby połączenia wychodzące z poszkodowanych usług nie otrzymywały odpowiedzi, co powodowało konieczność wycofania się z rynku. Nasz zespół inżynieryjny wykluczył konfigurację usług UiPath, politykę na poziomie aplikacji i przepustowość połączeń wychodzących jako przyczyny. Dostawca infrastruktury uznał znany problem dotykający wielu klientów na tej samej ścieżce sieciowej. # # Detection Kwestia ta została wykryta poprzez automatyczne monitorowanie. Około godziny 12: 40 UTC - mniej więcej dwie minuty po rozpoczęciu niepowodzenia - dochodzenie potwierdziło, że nowe połączenia z dotkniętych usług w regionie UAN do kluczowych punktów końcowych UiPath zawodzą. # # Response Do 13: 20 UTC, nasz zespół inżynieryjny potwierdził, że awaria była ograniczona do konkretnych ścieżek sieci wychodzących, podczas gdy inne miejsca docelowe pozostały dostępne. Walidacja wykluczyła zmiany routingu po stronie UiPath- side, zmiany konfiguracji treści, politykę poziomu aplikacji oraz problemy związane z przepustowością połączeń. Wraz z trzecim dostawcą infrastruktury otwarto sprawę o wysokiej intensywności wsparcia. O 13: 50 UTC, dostawca przyznał znany problem dotykający wielu klientów. Nasz zespół w dalszym ciągu monitorował odzyskiwanie z dotkniętych ścieżek sieciowych i weryfikował zdrowie usług po powrocie ruchu. O 14: 51 w UTC kontrole odzysku potwierdziły, że ruch UiPath przez dotknięte trasy dostarczania treści powrócił do normalnego poziomu. Automatyczne kontrole zdrowia i wskaźniki usług potwierdzone odzysk, a usługi w UAN były operacyjne. # Follow up 1. Ścigamy potwierdzone działania naprawcze dostawcy infrastruktury i analizę przyczyn dla regionalnych awarii routingu. 2. Przeanalizowujemy zewnętrzne zależności usługowe w regionie dotkniętym klęską, aby wzmocnić odporność na podobne zakłócenia sieci osób trzecich.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 2 października 2026 16:23 UTCinvestigating

   Od około 15: 05 UTC, niektórzy klienci w regionie USA mogą zobaczyć miejsca pracy, które prowadzone na Cloud Robots trwa dłużej niż zwykle, aby rozpocząć lub pozostać w stanie oczekującym. Praca na własnych robotach nie ma wpływu, podobnie jak inne regiony. Znaleźliśmy prawdopodobną przyczynę i pracujemy nad przywróceniem normalnej pracy. Miejsca pracy, które są już w kolejce, nie są stracone i będą przetwarzane po rozwiązaniu problemu. Prześlemy kolejną aktualizację w ciągu 60 minut.

2. 2 października 2026 16:34 UTCmonitoring

   Zastosowaliśmy rozwiązanie problemu, że opóźnione miejsca pracy na Cloud Robots w regionie USA, i miejsca pracy zaczynają się normalnie ponownie. Praca opóźniona jest obecnie rozpatrywana. Monitorujemy, żeby serwis pozostał stabilny i opublikujemy kolejną aktualizację w ciągu 60 minut.

3. 2 października 2026 16:51 UTCmonitoring

   Po dalszych pracach nad tym zagadnieniem, miejsca pracy związane z robotami w chmurze w regionie USA rozpoczynają się obecnie normalnie. Prace, które zostały wcześniej opóźnione, są przetwarzane. Kontynuujemy monitorowanie usługi i opublikujemy kolejną aktualizację po rozwiązaniu problemu.

4. 2 października 2026 17:03 UTCresolved

   Kwestia ta została rozwiązana. Między 15: 05 a 16: 39 UTC, miejsca pracy na Cloud Robots w regionie USA były powolne, aby rozpocząć lub zatrzymać się w stanie oczekującym. Praca zaczyna się normalnie od 16: 39 UTC, a miejsca pracy, które zostały opóźnione w tym czasie zostały już przetworzone. Przepraszamy za zakłócenia.

5. 14 października 2026 14:20 UTCpostmortem

   # # Wpływ na klienta Od 15: 00 do 16: 38 UTC na 2026-10-02, Cloud Robots pracy w regionie USA trwało dłużej niż zwykle, aby rozpocząć, do 22 minut na szczycie około 16: 20 UTC. Orchestrator pozostał dostępny, nie stracił pracy, żaden inny region nie został naruszony. Niewielka liczba klientów otrzymała tymczasowy błąd ograniczający nowe zgłoszenia, podczas gdy ich wcześniejsze miejsca pracy czekały. # # Detection Automatyczne alarmy wystrzelone o 15: 07 UTC, siedem minut po zderzeniu. Kontrole w regionie USA nie powiodły się od około 15: 32 UTC i rozpoczęła się reakcja na incydenty. # # Root cause O godzinie 14: 55 UTC jeden z klientów zaczął składać zlecenia w około 20 razy większym tempie. Usługa, która przyznaje pracę, utrzymuje w bazie danych liczbę kontraktów dla klienta i aktualizuje ją pod blokadą bazy danych przy każdym rozpoczęciu i zakończeniu pracy. W tym tempie kolejka blokady rekordu klienta rosła do czasu aktualizacji czasu. Oczekiwane aktualizacje zajmowały wspólną pulę pracowników, którzy rozpoczynają pracę dla wszystkich klientów w regionie, więc każda praca klienta czekała za nimi. Mechanizm mający na celu odizolowanie ładunku jednego klienta stał się wąskim gardłem. # # Response Zespół zidentyfikował przeciążoną ścieżkę wstępu i obciążenie pracą za nią. Pierwsza zmiana konfiguracji o 15: 46 UTC celowała w zły rekord i nie przyniosła efektu. Prawidłowa zmiana o 16: 10 UTC zwolniła ten typ pracy klienta z blokady bazy danych i weszła w życie około 16: 20 UTC. Czasy początkowe spadły z około 13 sekund do poniżej jednej sekundy, a zaległości około 5200 miejsc pracy wyczerpały się w 18 minut. Początek pracy był normalny o 16: 38 UTC. Zapalnik klienta został wyłączony z klientem około 16: 40 UTC. # Follow up Ograniczenie liczby zablokowanych danych zastępuje się mechanizmem ograniczania wysokiej wydajności w pamięci, tak więc obciążenie jednego klienta nie może blokować pracy dla innych. Zmiana jest kompletna, testowana w preprodukcji przy tym samym obciążeniu i jest toczona.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 2 października 2026 00:13 UTCinvestigating

   Obecnie badamy przestoje na portalu Insights w regionie ZEA. Użytkownicy w tym regionie mogą nie być w stanie uzyskać dostępu do portalu lub mogą doświadczyć nieudanego obciążenia strony. Nasz zespół aktywnie pracuje nad zidentyfikowaniem przyczyny i przywróceniem usługi. Dostarczymy kolejną aktualizację, jak tylko będziemy mieli więcej informacji.

2. 2 października 2026 00:36 UTCidentified

   Zidentyfikowaliśmy ścieżkę łagodzącą i rozpoczynamy wycofywanie w regionie ZEA. Użytkownicy mogą w dalszym ciągu doświadczać problemów związanych z nieregularnym dostępem do portalu Insights w trakcie prowadzonych prac. Dostarczymy kolejną aktualizację po zakończeniu procesu.

3. 2 października 2026 00:41 UTCmonitoring

   Portal Insights w regionie Zjednoczonych Emiratów Arabskich jest teraz ładowany pomyślnie po naszej rollback. Kontynuujemy monitorowanie służby w celu potwierdzenia stabilności i dostarczymy jej ostateczną aktualizację, gdy będziemy pewni, że problem został w pełni rozwiązany.

4. 2 października 2026 00:51 UTCresolved

   Portal Insights w regionie Zjednoczonych Emiratów Arabskich działa teraz normalnie po przejściu. Zatwierdzliśmy kluczową funkcjonalność portalu i potwierdziliśmy, że usługa pozostaje zdrowa. Ten incydent został rozwiązany.

5. 5 października 2026 22:58 UTCpostmortem

   # # Uderzenie klienta * * 1 października 2026 * * UiPath * * Insights * * service w regionie ZEA * * była niedostępna. Od około * * 23: 40 UTC w dniu 1 października do 00: 39 UTC w dniu 2 października * *, użytkownicy nie mogli załadować Deski rozdzielcze Insights: żądania nie powiodły się z błędem po około 10 sekundach. Wnioski o udostępnienie Invisions dla nowych najemców w regionie również nie powiodły się. Zakłócenie trwało około 59 minut. Inne usługi UiPath w regionie ZEA oraz Insights we wszystkich innych regionach nie zostały naruszone. Nie utracono danych klientów. # # Root Cause # Przerwę spowodowała zmiana konfiguracji * *, która została wysłana w planowanym wydaniu Insights. Zmiana podniosła wersję * * minimum TLS\ (Transport Layer Security\) * * na końcowych punktach aplikacji Insights w regionie ZEA z TLS 1.2 do * * TLS 1.3 * *, w ramach wysiłków na rzecz wzmocnienia bezpieczeństwa. Brama UiPath, która prowadzi ruch klientów do Insights, łączy się z tymi punktami końcowymi nad TLS 1.2. Kiedy punkty końcowe przestały akceptować TLS 1.2, brama nie mogła już otworzyć do nich bezpiecznego połączenia. Prośby klientów w czasie i zwrócone błędy, mimo że aplikacja Insights sama w sobie pozostała zdrowa. Zmiana miała zastosowanie wyłącznie do regionu ZEA, dlatego żaden inny region nie został naruszony. # # Detection Problem został wykryty przez zautomatyzowany monitoring syntetyczny UiPath * *, który stale bada dostępność Insights z wielu lokalizacji. Pierwsza nieudana ocena stanu zdrowia została odnotowana o 23: 40 UTC. Automatyczne alarmy wystrzeliły w ciągu kilku minut, a zespół inżynierów na wezwanie rozpoczął śledztwo. # # Response Zespół inżynieryjny potwierdził, że przerwa dotyczyła jedynie Insights w regionie ZEA. Aplikacja działała normalnie, ale żaden ruch klientów nie docierał do niej. Zespół śledził awarię połączenia bezpieczeństwa między bramą i Insights i połączył go z ustawieniem TLS zastosowanym przez wydanie. W przybliżeniu * * 00: 38 UTC * *, zespół przywrócił poprzednią minimalną wersję TLS\ (TLS 1.2\) na dotkniętych punktów końcowych. Syntetyczne kontrole zdrowotne zaczęły przechodzić natychmiast, a o 00: 41 UTC * * wszystkie kontrole Insights w regionie ZEA były zdrowe. Zespół monitorował, by potwierdzić pełną stabilność. # Follow-Up Aby zapobiec podobnym incydentom w przyszłości, podejmujemy następujące kroki: * * * Usuń zmianę TLS z wydania * * tak, aby przyszłe rozmieszczanie nie było ponownie stosowane, dopóki brama obsługuje TLS 1.3 kończy się. * * * Potwierdź zmiany w zakresie bezpieczeństwa połączeń z bramą * * w środowisku przedprodukcyjnym, zanim zostaną zastosowane do produkcji.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 1 października 2026 18:57 UTCinvestigating

   Począwszy od 1 października o godzinie 1: 30 PM UTC, niektórzy agenci, w tym zarówno niski kod, jak i zakodowane agentów, zaczęli doświadczać niepowodzeń we wszystkich regionach przy użyciu gemini- 3,1 -pro- podgląd i gpt- 4o- 2024- 05- 13. Modele te mogą być również niedostępne do wyboru podczas projektowania czynnika. Prowadzimy aktywne śledztwo i pracujemy nad tym.

2. 1 października 2026 19:05 UTCidentified

   Zidentyfikowaliśmy problem i wprowadzamy rozwiązanie. Agenci korzystający z dotkniętych modeli mogą w dalszym ciągu doświadczać awarii, a modele mogą pozostać niedostępne do selekcji podczas projektowania czynników, podczas gdy wdrożenie jest zakończone.

3. 1 października 2026 19:46 UTCresolved

   Odwróciliśmy zmianę, która spowodowała tę kwestię i potwierdziliśmy, że dotknięte nią modele są ponownie dostępne. Niektórzy agenci mogą w dalszym ciągu doświadczać przerywanych awarii, podczas gdy przypadki odświeżania. Kontynuujemy monitorowanie projektowania i wykonania agenta dla gemini- 3.1-pro- podglądu i gpt- 4o- 2024- 05- 13.

4. 7 października 2026 10:15 UTCpostmortem

   # # Wpływ na klienta W dniu 1 października 2026 r., od 14: 31 do 19: 40 UTC, agenci skonfigurowani z niektórymi dużymi modelami językowymi, w tym Gemini 3.1 Pro Preview i GPT- 4o (2024- 05- 13), nie zaczęli działać we wszystkich regionach, z błędem stwierdzającym, że model nie jest dostępny. Te same modele brakowało z listy modeli podczas projektowania agentów. Agenci stosujący inne modele nie ulegli zmianie. # # Root cause Flaga funkcji została przewrócona, co spowodowało, że służby agentów zaczęły wysyłać kod operacji na potrzeby wyszukiwania modeli. Spowodowało to, że lista modeli służyła do tej konkretnej operacji w przeciwieństwie do listy czynników podstawowych. Lista modeli dla każdej operacji została początkowo wyselekcjonowana z konfiguracji Bring Your Own Model (BYOM) dla modeli powtarzalnych, które przede wszystkim dla agentów nie miały parytetu z pełną listą obsługiwanych modeli w serwisie Agentów. Kontrola wewnętrzna wykazała, że był to błąd, a nie zamierzona luka. Z czasem ta luka nigdy nie została rozwiązana i po zmianie flagi, agenci już skonfigurowani z którymkolwiek z dotkniętych modeli nie powiodły się ze względu na ich nieobecność na liście zwróconej. # # Detection Klient zgłosił ten problem, i został eskalowany do naszych inżynierów o 16: 44 UTC. Nasz monitoring nie zaalarmował, ponieważ ten błąd zazwyczaj wskazuje na problemy z konfiguracją na poziomie organizacji lub agenta. # # Response Inżynierowie namierzyli awarię zmiany konfiguracji i cofnęli ją o 19: 01 UTC. Zwrócenie nastąpiło w ciągu kolejnych minut, a ostatnia awaria nastąpiła o 19: 40 UTC. # Follow up 1. Listy modeli zostaną dostosowane przed dokonaniem tej zmiany ponownie. 2. Zmieniamy sposób, w jaki ten błąd jest klasyfikowany, tak aby na platformach ostrzegał naszych inżynierów.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 1 października 2026 18:17 UTCinvestigating

   Począwszy od 1 października o godz. 12: 00 UTC, użytkownicy społeczności w Europie mogą doświadczać niepowodzeń w agentach LowCode, które korzystają z lokalnych aplikacji do działań. Potwierdziliśmy, że wpływ ten ogranicza się do użytkowników wspólnotowych w Europie. Aktywnie badamy tę kwestię, określamy zakres niepowodzeń i pracujemy nad ustaleniem rozwiązania.

2. 1 października 2026 18:25 UTCidentified

   Zidentyfikowaliśmy problem powodujący awarie w agentach o niskim kodzie, które wykorzystują lokalne aplikacje do działań dla użytkowników społecznych w Europie. Wycofujemy poprzednie zmiany i kontynuujemy monitorowanie ożywienia gospodarczego. Dostarczymy kolejną aktualizację po zakończeniu rollback lub jeśli mamy dodatkowe informacje do udostępniania.

3. 1 października 2026 20:08 UTCresolved

   Potwierdziliśmy, że cofnięcie zostało zakończone, a problem dotykający agentów o niskim kodzie, którzy korzystają z aplikacji rozwiązywania problemów lokalnych dla użytkowników w Europie, został rozwiązany. Służby wyzdrowiały i zamykamy ten incydent.

4. 7 października 2026 14:28 UTCpostmortem

   # # Wpływ na klienta W dniu 1 października 2026, od 10: 50 do 19: 50 UTC, niektórzy użytkownicy Studio Web w Europie nie mogli debugować agentów, którzy nazywają procesy Orchestratora (RPA, agenci, itp.) lub Action Apps z tego samego rozwiązania. Połączenie nie powiodło się z błędem "nie znaleziono". Agenci publikujący i miejsca pracy produkcyjne nie zostały naruszone. # # Root cause Aktualizacja Studio Web zmieniła sposób lokalizacji zasobów rozwiązań podczas debugowania. Brakowało ustawienia, które utrzymuje poprzednie zachowanie, więc debug uruchomiony szukał zasobów rozwiązania w osobistej przestrzeni roboczej użytkownika zamiast folderu debug. # # Detection Automatyczne testy końcowe zaalarmowały naszych inżynierów o 16: 43 UTC. Komplet testowy end-to@-@ end działa raz na 2 godziny i ostrzeganie następuje tylko po 3 kolejnych niepowodzeniach. Problem ten został również zgłoszony z otoczenia klienta. # # Response Po zidentyfikowaniu przyczyny, rollback został uruchomiony o 18: 00 UTC i był w pełni skuteczny o 19: 50 UTC. Okres ten obejmował awarię rozmieszczenia, która musiała zostać ponownie wypróbowana, która trwała 50 minut. Wersja poprawiona, która zawiera ustawienie została uruchomiona 2 października o godzinie 13: 00 UTC. # Follow up 1. Ustawienie jest teraz częścią głównego kodu linii, więc przyszłe wydania obejmują to. 2. Ulepszamy alarmy i zestaw testów end-to-end, aby wcześniej złapać regresje.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 1 października 2026 16:32 UTCresolved

   Między 14: 23 a 16: 04 UTC w dniu 1 października 2026 r. niektóre wnioski o usunięcie elementów w usługach UiPath Automation Cloud w regionie Australii nie powiodły się z błędami "404 not found". Usługi dotknięte to Orchestrator, Document Understanding, AI Center i usługi danych. Inne operacje, takie jak przeglądanie, tworzenie i aktualizacja elementów, działały normalnie. Przyczyną była zmiana konfiguracji naszego polecenia. Odwróciliśmy go i usługa została w pełni przywrócona.

2. 7 października 2026 10:15 UTCpostmortem

   # # Wpływ na klienta Między 1 października 2026 o 14: 23 UTC i 16: 04 UTC, podzbiór klientów doświadczył * * 404 Nie znaleziono * * błędów dla niektórych żądań UiPath Automation Cloud w regionie Australii. Incydent trwał godzinę i 41 minut. Nawiązane z tym żądania obejmują usunięcie operacji i niektórych kontroli połączeń Robot. Usługi dotknięte to Orchestrator, Document Understanding, AI Center i usługi danych. Roboty, które nazywane Orchestrator może nie powiodły się, a klienci mogą potrzebować ponownie uruchomić wszystkie Roboty, które zawiodły podczas tego okna. Wszystkie inne operacje nie zostały naruszone. # # Root cause Zmiana konfiguracji trasy została zastosowana w regionie Australii z niepełnym zestawem obsługiwanych operacji ze względu na czas w gazociągu uwolnienia. W konfiguracji brakuje operacji usunięcia, więc wnioski te zostały odrzucone na warstwie routingu z * * 404 Nie znaleziono * * przed dotarciem do podstawowych usług. # # Detection Automatyczne monitorowanie końcowe wykryło tę kwestię, informując o błędach w kontrolach usług Document Understanding. Nasz zespół inżynieryjny wykorzystał dane z monitoringu wewnętrznego, aby potwierdzić szerszy wzorzec awarii w obrębie usług, które ucierpiały. # # Response W trakcie dochodzenia dane z monitorowania wykazały, że wnioski kierowane w regionie Australii były zwracane * * 404 Nie znaleziono * *, podczas gdy wnioski kierowane w innych regionach nie zostały naruszone. Analiza wykazała, że czas rozpoczęcia * * 404 Nie znaleziono * * Zwiększenie odpowiedzi było skorelowane z czasem, kiedy konfiguracja routingu weszła w życie. Zespół odwrócił konfigurację routingu do poprzedniej wersji roboczej. Po powrocie monitoring wykazał, że liczba błędów spada w ciągu około trzech minut, a usługa została w pełni przywrócona do 1 października 2026 o 16: 04 UTC. # Follow up 1. Poprawa ostrzeżeń warstw routingu o zmianach wyjściowych 4xx 2. Wykrywanie częściowo zastosowanych konfiguracji routingu przed ich wejściem w życie

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.