Historia awarii Uipath

1. 3 września 2026 15:34 UTCinvestigating

   Obecnie badamy tę sprawę

2. 3 września 2026 15:39 UTCidentified

   Zidentyfikowano tę kwestię i wprowadzono odpowiednie środki łagodzące w celu jej rozwiązania.

3. 3 września 2026 15:47 UTCmonitoring

   Sprawa została pomyślnie rozwiązana, a usługa została w pełni przywrócona. Usługa działa normalnie w tym czasie.

4. 3 września 2026 16:17 UTCresolved

   Sprawa została pomyślnie rozwiązana, a usługa została w pełni przywrócona. Usługa działa normalnie w tym czasie.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 4 września 2026 17:48 UTCresolved

   Deska rozdzielcza Insights w Looker doświadczyła problemu, który zapobiegł pojawieniu się w desce rozdzielczej najnowszego Maestro Regiony dotknięte skutkami: US, SEA, IND, CA, AUE, JP, UK Terminy incydentów Rozpoczęty: 2 września 2026 o 20: 00: 00 UTC Uzgodnione: 4 września 2026 o 16: 30: 00 UTC Problem został obecnie rozwiązany, a tablica rozdzielcza Insights wyświetla najnowsze dane Maestro.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 1 września 2026 13:49 UTCinvestigating

   Badamy raporty o zdegradowanej wydajności wpływającej na digitalizację i wydobycie w USA dla Zrozumienia Dokumentów i IXP. Impact: Użytkownicy mogą doświadczać spowolnienia i nieudanej pracy w czasie pracy w zakresie rozumienia dokumentów. Nasze zespoły pracują nad zidentyfikowaniem przyczyny i będą dzielić się więcej szczegółów w miarę postępu śledztwa.

2. 1 września 2026 14:07 UTCmonitoring

   Zidentyfikowaliśmy tę kwestię i zastosowaliśmy środki łagodzące. Usługi powracają do zdrowego stanu, a my ich monitorujemy.

3. 1 września 2026 15:06 UTCresolved

   Kwestia ta została w pełni rozwiązana, a usługi są teraz stabilne. Wkrótce opublikujemy więcej szczegółów na stronie.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 31 sierpnia 2026 16:55 UTCinvestigating

   Obecnie badamy tę sprawę.

2. 31 sierpnia 2026 17:07 UTCidentified

   Zidentyfikowaliśmy problem i wdrożyliśmy niezbędne rozwiązanie

3. 31 sierpnia 2026 18:24 UTCmonitoring

   Kwestia ta została złagodzona, a usługa jest obecnie dostępna. Będziemy nadal uważnie monitorować zdrowie usług i w razie potrzeby podejmować dalsze działania.

4. 31 sierpnia 2026 19:39 UTCresolved

   Kwestia ta została złagodzona, a usługa jest obecnie dostępna. Będziemy nadal uważnie monitorować zdrowie usług i w razie potrzeby podejmować dalsze działania.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 28 sierpnia 2026 15:41 UTCidentified

   Problem został zidentyfikowany, a zespół aktywnie pracuje nad wdrożeniem rozwiązania. Oczekujemy, że rozmieszczenie rozpocznie się w najbliższych godzinach.

2. 28 sierpnia 2026 17:27 UTCmonitoring

   Zidentyfikowaliśmy główną przyczynę zdegradowanego działania i jesteśmy w trakcie wdrażania rozwiązania w nadchodzących godzinach. Dotyczy powiązanych zapytań, w których użytkownik nie ma dostępu do oryginalnego folderu. Powierzchnia API jest nienaruszona. Eksport za pośrednictwem CSV może być wykorzystywany jako obejście. Dodatkowe aktualizacje zostaną dostarczone w miarę zbliżania się do rezolucji.

3. 28 sierpnia 2026 17:39 UTCidentified

   Zidentyfikowaliśmy główną przyczynę zdegradowanego działania i jesteśmy w trakcie wdrażania rozwiązania w nadchodzących godzinach. Dotyczy powiązanych zapytań, w których użytkownik nie ma dostępu do oryginalnego folderu. Powierzchnia API jest nienaruszona. Eksport za pośrednictwem CSV może być wykorzystywany jako obejście. Dodatkowe aktualizacje zostaną dostarczone w miarę zbliżania się do rezolucji.

4. 28 sierpnia 2026 20:00 UTCidentified

   Fix jest obecnie stosowany. Dostarczymy kolejną aktualizację wkrótce po zakończeniu rozmieszczenia we wszystkich dotkniętych regionach.

5. 28 sierpnia 2026 22:57 UTCresolved

   Rozwiązanie zostało pomyślnie wdrożone we wszystkich regionach i potwierdziliśmy, że problem został rozwiązany. Usługa działa zgodnie z oczekiwaniami.

6. 3 września 2026 08:49 UTCpostmortem

   # # Wpływ na klienta Między 28 sierpnia 2026 o 15: 23 UTC a 28 sierpnia 2026 o 22: 57 UTC, podzbiór klientów doświadczył błędów podczas otwierania paneli elementów kolejki w Orchestratorze. Uszkodzona ścieżka zwróciła 404 strony dla kolejek LINKED, kiedy użytkownik NIE miał dostępu do oryginalnego folderu, w którym zostały utworzone elementy. Wpływ dotyczył tylko interakcji UI Orchestratora i rozprzestrzenił się we wszystkich regionach, uruchamiając wersję oprogramowania. Dostęp do interfejsu programowania aplikacji Orchestratora nie został naruszony, a dane dotyczące kolejki eksportu do CSV były dostępne w ramach pracy. Całkowity czas trwania leczenia wynosił około 7 godzin. # # Root cause Incydent został spowodowany regresją interfejsu użytkownika Orchestratora dla powiązanych kolejek dostępnych z innych folderów. Regresja nie prawidłowo obsługiwać linked- kolejka szczegóły przepływu, gdy wnioskujący użytkownik nie miał dostępu do oryginalnego folderu, co spowodowało, że szczegóły pozycji kolejki do trasy do 404 strony zamiast wyświetlania oczekiwanych informacji. # # Detection Kwestia ta została wykryta przez automatyczny alarm incydentu na froncie Orchestratora 28 sierpnia 2026 o 15: 23 UTC. # # Response O 15: 31 UTC 28 sierpnia 2026 roku, nasz zespół inżynieryjny opisał ten problem jako klientów, którzy nie mogą uzyskać dostępu do paneli elementów kolejki ze względu na regresję. O 15: 41 UTC, aktualizacja statusu publicznego potwierdziła, że przyczyna została zidentyfikowana, że została wprowadzona fix, a dostęp do interfejsu programowania aplikacji nie został naruszony. O 17: 27 UTC, zakres został ograniczony do powiązanych kolejek, gdzie użytkownik nie miał dostępu do oryginalnego folderu. O 17: 29 zespół ustalił, że początkowe rozwiązanie nie było w pełni dostosowane do danego scenariusza, a poprawione rozwiązanie zostało opracowane. O 17: 30 UTC został odtworzony scenariusz, a poprawiony fix został zatwierdzony lokalnie. O 17: 39 UTC, aktualizacja strony statusu udokumentowana eksport CSV jako obejście. Wdrożenie poprawionej poprawki kontynuowano we wszystkich dotkniętych regionach. O 22: 50 UTC, wszystko zostało potwierdzone. O 22: 57 UTC, incydent został rozwiązany i strona statusu została zaktualizowana, aby potwierdzić, że usługa działała zgodnie z oczekiwaniami. # Follow up Formalne działania następcze są śledzone w procesie przeglądu po incydencie zainicjowanym w trakcie restrukturyzacji i uporządkowanej likwidacji. # # Pozycje działania - Rozszerzenie naszych zautomatyzowanych przypadków testowych w celu uwzględnienia tego scenariusza oraz innych podobnych scenariuszy związanych z powiązanymi obiektami lub scenariuszami folderów krzyżowych. - Zapewnienie bezpiecznego wyłączania wszelkich zmian za pomocą flagi na szybszy czas reakcji.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 27 sierpnia 2026 17:16 UTCinvestigating

   Prowadzimy śledztwo w sprawie brakujących dzienników robotów w regionie USA. Nasze zespoły pracują nad zidentyfikowaniem przyczyny i będą dzielić się więcej szczegółów w miarę postępu śledztwa.

2. 27 sierpnia 2026 18:53 UTCidentified

   Zidentyfikowaliśmy, że spożycie logarytmu robota było opóźnione. Rejestry robotów nadrabiają zaległości w zbieraniu danych na żywo, a my monitorujemy odzysk.

3. 27 sierpnia 2026 20:31 UTCmonitoring

   Logi są teraz populowane zgodnie z oczekiwaniami w czasie rzeczywistym i będziemy nadal monitorować stosowanie.

4. 27 sierpnia 2026 21:57 UTCresolved

   Sprawa została rozwiązana, a dzienniki są popularyzowane zgodnie z oczekiwaniami.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 25 sierpnia 2026 09:41 UTCidentified

   Zidentyfikowaliśmy problem wpływający na funkcję Solution Deployment w Studio Web w regionie Japonii, gdzie wdrażanie rozwiązań może się nie udać. Ustawienie zostało już przygotowane i wkrótce będzie gotowe. Dostarczymy dalsze aktualizacje w miarę dostępności większej ilości informacji.

2. 25 sierpnia 2026 09:47 UTCmonitoring

   Rozwiązanie zostało pomyślnie wdrożone w regionie Japonii, a problem został złagodzony. Ściśle monitorujemy usługę w celu zapewnienia, że wdrażanie rozwiązań będzie nadal działać zgodnie z oczekiwaniami i w razie potrzeby zapewni dalsze aktualizacje.

3. 25 sierpnia 2026 10:12 UTCresolved

   Problem został rozwiązany, a Solution Deployment in Studio Web działa zgodnie z oczekiwaniami w regionie Japonii. Nie zaobserwowano dalszego wpływu.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 25 sierpnia 2026 03:58 UTCinvestigating

   Badamy problem dotykający klientów korzystających z Insights w regionie Singapuru, gdzie deski rozdzielcze mogą nie załadować i wyświetlić błędów czasowych. Nasze zespoły pracują nad zidentyfikowaniem przyczyny i dostarczą dalszych aktualizacji w miarę dostępności większej ilości informacji.

2. 25 sierpnia 2026 04:37 UTCmonitoring

   Kwestia ta została złagodzona i ściśle monitorujemy usługi Insights w regionie Singapuru, aby zapewnić, że deski rozdzielcze nadal ładują się zgodnie z oczekiwaniami.

3. 25 sierpnia 2026 04:53 UTCresolved

   Problem został rozwiązany, a Insights Service w regionie Singapuru działa zgodnie z oczekiwaniami. Nie zaobserwowano dalszego wpływu.

4. 4 września 2026 11:46 UTCpostmortem

   # # Wpływ na klienta Między 25 sierpnia 2026 o 3: 42 rano UTC i 25 sierpnia 2026 o 4: 53 rano UTC, klienci korzystający z Insights w regionie Singapuru doświadczyli niepowodzeń w ładowaniu desek rozdzielczych Insights. Związani z tym użytkownicy widzieli, że strony na desce rozdzielczej nie są wczytywane, a błędy serwera były obserwowane w przypadku związanych z nimi żądań serwisowych. Głównym skutkiem był dostęp Insights do tablicy rozdzielczej, w tym wykresów i alarmów. Powiązana usługa backend również zwróciła błędy serwera podczas incydentu, ale dostęp do deski rozdzielczej odzyskał przed ostateczną rozdzielczością. # # Root cause Incydent został przypisany regionalnemu zakłóceniu usługi Microsoft w Singapurze wpływającemu na infrastrukturę wykorzystywaną przez usługę Insights. Podczas zakłóceń, usługa Insights nie była w stanie niezawodnie obsługiwać żądań deski rozdzielczej, co skutkowało przerwami czasowymi i błędami serwera. Po naszej stronie nie wprowadzono żadnych zmian. Usługa odzyskana po rozwiązaniu zakłóceń regionalnych Microsoft, a następnie Microsoft zgłosił kwestię usług regionalnych Singapur na swojej stronie statusu. Firma Microsoft zwróciła się o formalną analizę przyczyn, aby potwierdzić specyficzny mechanizm niepowodzenia i określić dodatkowe środki zapobiegawcze lub łagodzące. # # Detection Automatyczne monitorowanie stanu zdrowia w usłudze Insights wykryło problem na 25 sierpnia 2026 o 3: 42 UTC. Wpływ na klienta został potwierdzony na moście odpowiedzi krótko po wykryciu. # # Response W dniu 25 sierpnia 2026 o 3: 58 rano UTC, opublikowaliśmy publiczną aktualizację statusu, zauważając, że Insights deski rozdzielcze w regionie Singapuru może nie załadować i wyświetlić błędy timeout. Podczas reakcji nasz zespół inżynieryjny zweryfikował błędy serwera w automatycznym monitorowaniu, próbował uzyskać dostęp do diagnostyki usług i rozpoczął procedurę odzyskiwania podstawowej infrastruktury. W dniu 25 sierpnia 2026 o 4: 01 rano UTC, Insights Service odzyskał podczas procedury odzyskiwania było w toku, a załadunek deski rozdzielczej został zatwierdzony na wielu kontach testowych. W dniu 25 sierpnia 2026 o 4: 37 w UTC, przenieśliśmy incydent do monitorowania po potwierdzeniu desek rozdzielczych załadowanych pomyślnie. Powiązane usługi backend odzyskane w dniu 25 sierpnia 2026 o 4: 49 UTC, a incydent został oznaczony w dniu 25 sierpnia 2026 o 4: 53 UTC. # Follow up 1. Poproś o analizę przyczyn źródłowych z Microsoft na zakłócenie regionalne Singapuru wpływające na spostrzeżenia deski rozdzielcze problemu załadunku.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 25 sierpnia 2026 03:44 UTCinvestigating

   Badamy problem dotykający klientów wykorzystujących rozszerzoną funkcjonalność OCR w usłudze Document Understanding w regionie Singapuru. Nasze zespoły pracują nad zidentyfikowaniem przyczyny i dostarczą dalszych aktualizacji w miarę dostępności większej ilości informacji.

2. 25 sierpnia 2026 04:04 UTCmonitoring

   Kwestia ta została złagodzona i ściśle monitorujemy usługę, aby zapewnić jej kontynuację zgodnie z oczekiwaniami. Dostarczymy dalsze aktualizacje w miarę dostępności większej ilości informacji.

3. 25 sierpnia 2026 04:59 UTCresolved

   Problem został rozwiązany, a usługa działa zgodnie z oczekiwaniami. Nie obserwowano dalszych skutków.

4. 27 sierpnia 2026 03:42 UTCpostmortem

   # # Wpływ na klienta W dniu 25 sierpnia 2026 r., rozszerzone żądania OCR w serwisie Document Understanding nie powiodły się z 500 kodem statusu w regionie Singapuru przez około 33 minuty, między 03: 08 a 03: 41 UTC. Przyczyną było zakłócenie usługi regionalnej Microsoft w Singapurze. Wszystkie inne funkcje Zrozumienia Dokumentów nie zostały naruszone i żaden inny region nie został naruszony. # # Root cause Niepowodzenie zostało przypisane regionalnemu zakłóceniu usługi Microsoft w Singapurze wpływającemu na zasoby wykorzystywane przez rozszerzoną zdolność OCR. Nie wprowadzono żadnych zmian po naszej stronie, a Microsoft następnie uaktualnił swoją stronę statusu, aby odzwierciedlić kwestię regionalną Singapuru. Formalna analiza przyczyn została zażądana od Microsoft. # # Detection Automatyczny alarm dla usługi Document Understanding uruchomiony 25 sierpnia 2026 o 3: 13 w UTC. Alarm został natychmiast potwierdzony, a incydent został uznany za wpływający na klienta w ciągu kilku minut. # # Response Inżynier on-call zbadał wpływ na region Singapuru. Respondenci wykluczyli niedawną aktualizację usług jako przyczynę, ponieważ ta sama aktualizacja została wdrożona do innych regionów, które nie mają porównywalnych skutków, co wskazuje na niepowodzenie w zakresie zależności regionalnej poza naszą infrastrukturą. Ponieważ awaria powstała w usłudze Microsoft, nie było żadnych działań łagodzących po stronie UiPath. Prośby zaczęły się ponownie o 03: 41 UTC, po odzyskaniu zależności Microsoft. Respondenci utrzymywali, że incydent był otwarty, aby zweryfikować trwały powrót do zdrowia: 10 minut czystego ruchu zostało potwierdzone o 03: 51 UTC, incydent przeniósł się do Monitoring o 04: 04 UTC, a został rozwiązany o 04: 59 UTC po stałej stabilności bez dalszych błędów. # Follow up 1. Zwrócił się do Microsoft o przeprowadzenie analizy przyczyn głównych zakłóceń regionalnych w Singapurze mających wpływ na poszerzone uzależnienia od OCR, w tym jak można zapobiec nawrotom.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 24 sierpnia 2026 10:43 UTCidentified

   Zidentyfikowaliśmy przyczynę problemu wpływającego na niewielką liczbę klientów korzystających z UiPath Apps autorstwa serwisu Studio Web w wielu regionach. Nasze zespoły są gotowe, a rozmieszczenie zaczyna się w dotkniętych regionach. Będziemy nadal monitorować wdrażanie i dostarczać dalsze aktualizacje w miarę, jak fix staje się skuteczny.

2. 24 sierpnia 2026 11:30 UTCmonitoring

   Rozwiązanie to zostało pomyślnie zastosowane we wszystkich dotkniętych regionach, a problem został złagodzony. Ściśle monitorujemy usługę w celu zapewnienia, że fix nadal działa zgodnie z oczekiwaniami i w razie potrzeby zapewni dalsze aktualizacje.

3. 24 sierpnia 2026 11:55 UTCresolved

   Problem został rozwiązany, a usługa działa zgodnie z oczekiwaniami. Nie obserwowano dalszych skutków.

4. 1 września 2026 11:47 UTCpostmortem

   # # Wpływ na klienta Pomiędzy 19 sierpnia 2026 o 14: 33 UTC a 24 sierpnia 2026 o 11: 30 UTC, podzbiór klientów nie mógł załadować projektów UiPath Apps autorstwa Studio Web. Dotknięci klienci doświadczyli kompletnej niedostępności projektów Apps, a nie spowolnienia lub degradacji wydajności. Wpływ ten ograniczono do niewielkiej grupy klientów, których usługi app były świadczone w regionie Japonii. Całkowity czas oddziaływania na użytkownika wynosił około 4 dni i 21 godzin. # # Root cause Przyczyną było niedopasowanie aplikacji Studio Web i UiPath Apps. W dniu 19 sierpnia 2026 r. Studio Web otrzymało planową aktualizację w regionie UE obejmującą aktualizację ramową. Odpowiednie aktualizacje UiPath Apps zawierające aktualizację ramową nie zostały jeszcze wprowadzone do japońskiej jednostki skali. Wcześniejsza aktualizacja aplikacji, która była już zgodna z nową wersją ramową, została wdrożona we wszystkich regionach z wyjątkiem Japonii, gdzie rozmieszczenie zostało odroczone z przyczyn niezwiązanych. W rezultacie region Japonii nadal prowadził starszą wersję Apps, która nie była kompatybilna z uaktualnionym Studio Web. # # Detection Kwestia została zgłoszona przez klienta za pośrednictwem ich zespołu UiPath 24 sierpnia 2026 o 9: 36 UTC. Incydent został otwarty o 10: 21 rano UTC, a w ciągu minuty ogłoszono incydent na stronie publicznej. Istniejące zautomatyzowane monitorowanie nie wykryło problemu, ponieważ potwierdza dopasowane kombinacje wdrożeniowe; poprawa wykrywania konfiguracji mieszanych jest częścią naszego planu działań następczych. # # Response W ciągu kilku minut od otwarcia incydentu, zidentyfikowaliśmy niedopasowanie rozmieszczenia jako główną przyczynę i postanowiliśmy przyspieszyć wdrożenie odpowiedniej aktualizacji UiPath Apps do wszystkich dotkniętych regionów, dostosowując aplikacje do wersji Studio Web już obsługiwane do wpływających klientów. O 10: 43 w UTC opublikowaliśmy aktualizację stanu publicznego potwierdzającą, że przyczyna została zidentyfikowana i że naprawiono. O 10: 52 nad UTC, rozmieszczenie było w toku dla pozostałych regionów, a kilka regionów było już ukończonych. O 11: 30 nad UTC, potwierdziliśmy, że naprawiono wszystkie dotknięte obszary i zaznaczyliśmy, że incydent został złagodzony. O 11: 55 nad UTC, po tym jak monitorowanie nie wykazało dalszego wpływu, incydent został rozwiązany. # Follow up 1. Dodaj automatyczne ostrzeganie telemetrii produkcyjnej, aby wykryć awarie obciążenia aplikacji, skorelowane z obsługiwaną wersją Studio Web. 2. Wdrożenie monitorowania syntetycznego, który regularnie ładuje projekt Apps autorstwa Studio Web w reprezentatywnej konfiguracji klienta i alarmów o awarii. 3. Dostosuj sekwencjonowanie wydania dla ściśle sprzężonych zmian Studio Web i Apps tak, aby zależne aktualizacje Apps były w pełni stosowane we wszystkich regionach, zanim nowsze doświadczenie Studio Web dotrze do ruchu klienta.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 21 sierpnia 2026 12:37 UTCmonitoring

   Zastosowano rozwiązanie dotyczące kwestii wpływającej na klasyfikację i ekstrakcję dokumentów w USA, a obecnie monitorujemy wyniki.

2. 21 sierpnia 2026 13:36 UTCresolved

   Kwestia wpływająca na klasyfikację i ekstrakcję dokumentów w celu ich zrozumienia w regionie USA została rozwiązana. Po okresie monitorowania, usługa jest potwierdzona zdrowe i działa normalnie.

3. 27 sierpnia 2026 03:46 UTCpostmortem

   # # Wpływ na klienta Między 21 sierpnia 2026 o godz. 11: 05 UTC a 21 sierpnia 2026 o godz. 12: 18 UTC, podzbiór klientów doświadczył nieudanych operacji Document Understanding, w tym klasyfikacji dokumentów, ekstrakcji i digitalizacji. Szacunkowy czas trwania częściowego przerwania leczenia wynosił 48 minut. Wpływ był ograniczony do klientów korzystających z Document Understanding w regionie USA. # # Root cause Incydent został spowodowany przez konfigurację bazy danych Document Understanding, wprowadzającą stan przerwany podczas operacji rozszerzania bazy danych zapobiegawczych. Skale- up został zainicjowany po tym, jak baza danych zbliżyła się do limitu pamięci. Podczas operacji wtórna baza danych nie mogła być skalowana, próba usunięcia z konfiguracji awarii nie powiodła się, a dostawca platformy bazy danych musiał przerwać łącze replikacji. Pozostawiło to konfigurację przełączania awarii w tymczasowym stanie niedostępności, powodując, że usługi przechowywania i runtime, które zależą od tej bazy danych, zawiodą żądania. # # Detection Incydent został wykryty poprzez automatyczny wpis dotyczący usług w zakresie przetwarzania dokumentów, który został potwierdzony 21 sierpnia 2026 r. o godz. 12.10 czasu UTC. # # Response Przed ogłoszeniem incydentu wpływającego na klienta, pierwotna skala bazy danych została zakończona, a wsparcie ze strony dostawcy platformy bazy danych zostało uruchomione do wtórnego wydania bazy danych. Po zerwaniu konfiguracji default-over badaliśmy przekierowanie połączenia usługi, ale nie mogliśmy zidentyfikować bezpiecznej, natychmiastowej ścieżki do tego, biorąc pod uwagę bieżącą konfigurację usługi. Usługa została przywrócona poprzez usunięcie niezdrowej wtórnej bazy danych i odtworzenie konfiguracji awarii. Do 21 sierpnia 2026 o 12: 37 UTC, fix został wdrożony i monitoring był w toku. O 13: 36 w UTC, monitoring potwierdził, że usługa była zdrowa, a incydent został rozwiązany. # Follow up 1. Poproś o analizę przyczyny roota od dostawcy platformy bazy danych, aby ustalić, dlaczego wtórna baza danych nie może być skalowana i dlaczego rekultywacja konfiguracji awarii wymaga pęknięcia replikacji. 2. Aktualizacja bazy danych ostrzegających o progach i routingu, więc alarmy są przypisane i działają wcześniej, w tym ostrzeżenia o niższej ciężkości przy 75% wykorzystania i ostrzeżenie o wyższej ciężkości przy 85% użytkowania.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 19 sierpnia 2026 16:34 UTCinvestigating

   Badamy problem, który może mieć wpływ na niektórych klientów przy użyciu Claude Sonnet 4.6 w Agentach w regionie USA. Nasz zespół inżynieryjny aktywnie pracuje nad zrozumieniem tej kwestii i będzie udostępniał dalsze aktualizacje w miarę dostępności większej ilości informacji.

2. 19 sierpnia 2026 16:40 UTCmonitoring

   Złagodziliśmy problem. Nasz zespół inżynieryjny jest aktywnie rano i będzie dzielić się dalszymi aktualizacjami, jak więcej informacji staje się dostępne.

3. 19 sierpnia 2026 16:42 UTCmonitoring

   Złagodziliśmy problem. Nasz zespół inżynieryjny aktywnie monitoruje i będzie udostępniał dalsze aktualizacje w miarę dostępności dalszych informacji.

4. 19 sierpnia 2026 16:55 UTCresolved

   Sprawa została rozwiązana.

5. 31 sierpnia 2026 12:41 UTCpostmortem

   # # Uderzenie klienta Między 19 sierpnia 2026 o 13: 36 UTC a 19 sierpnia 2026 o 15: 53 UTC, podgrupa klientów otrzymała błędy podczas używania Claude Sonnet 4.6 w Agentach. Uderzenie trwało około 2 godzin i 17 minut. Wpływ miał na klientów korzystających z agentów w regionie USA. Zaobserwowano również błędy w odniesieniu do Claude Opus 4.6 i Claude Opus 4.5, które są stosowane w mniejszej objętości. - # # Root Cause # W ramach planowanej migracji infrastrukturalnej przenieśliśmy usługę platformy, która przekierowuje żądania modeli dla agentów na nowy system dostarczania konfiguracji, region po regionie. W nowym źródle konfiguracji brakowało danych dotyczących trzech modeli Claude 'a - Claude Sonnet 4.6, Claude Opus 4.6 i Claude Opus 4.5. Bez tych wpisów usługa nie mogła rozwiązać ważnego miejsca przeznaczenia dla wniosków do tych modeli i odrzuciła je z błędami. Inne modele nie zostały naruszone i nadal służą normalnie przez cały czas. - # # Detection Kwestia ta została wykryta przez eskalacji klientów 19 sierpnia 2026 o 14: 55 UTC - około 1 godziny i 19 minut po pierwszym dotkniętym wniosku. Nasz zespół inżynieryjny zbadał sprawę i rozpoczął śledztwo. Komunikacja o stanie publicznym rozpoczęła się o 15: 08 UTC. Nasze monitorowanie alarmowe opiera się na zagregowanych wskaźnikach błędów. Chociaż prawie wszystkie wnioski dotyczące trzech odnośnych modeli były nieskuteczne, modele te stanowiły niewielką część ogólnego ruchu w regionie, tak więc łączny sygnał nie przekroczył naszych progów ostrzegawczych i kwestia ta nie została automatycznie podniesiona. Jest to luka w wykrywaniu, o której mowa poniżej. - # # Response O 15: 25 UTC, niekompletne źródło konfiguracji zostało zidentyfikowane jako przyczyna, a fix został uruchomiony. O 15: 47 UTC, rozmieszczenie fix było w toku, a usługa była aktywnie monitorowana w miarę zmian. Do 15: 59 UTC, logi serwisowe potwierdziły, że problem został złagodzony, a o 16: 00 UTC wskaźnik awarii został potwierdzony na 0%. Incydent został oznaczony na 16: 40 UTC, a pełna rozdzielczość została zadeklarowana o 16: 55 UTC po ciągłym monitorowaniu i potwierdzeniu klienta, że usługa działa zgodnie z oczekiwaniami. - # Follow-Up Migracja infrastrukturalna została zakończona we wszystkich regionach i konfiguracja trasy pochodzi teraz z jednego źródła, usuwając niedopasowanie, które spowodowało ten incydent, więc nie może się powtórzyć. Wprowadza się automatyczne kontrole w celu ciągłej weryfikacji każdego obsługiwanego modelu w każdym regionie, tak więc niedostępny model jest natychmiast wykrywany i alarmowany - w tym w regionach o niskim natężeniu ruchu.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 18 sierpnia 2026 17:54 UTCinvestigating

   Badamy doniesienia o niepowodzeniu w ocenach ekspresji związanych z parametrami wyjściowymi zadania HITL dla Asgestic Orchestratron u użytkowników wspólnotowych w Europie. Wpływ: Użytkownicy mogą nie być w stanie wykonać zadań HITL Następna aktualizacja: Nasze zespoły pracują nad zrozumieniem przyczyny i zakresu i udostępnią aktualizacje w miarę dostępności.

2. 18 sierpnia 2026 20:31 UTCidentified

   Zidentyfikowaliśmy przyczynę wystąpienia zaburzeń w ocenach ekspresji związanych z parametrami wyjściowymi zadań HITL dla Agretic Orchestration u użytkowników wspólnotowych w Europie. Impact: Użytkownicy będą doświadczać niepowodzeń, gdy będą mieli wyrażenia przy użyciu parametru wyjścia zadania HITL. Następna aktualizacja: Nasze zespoły pracują nad zrozumieniem przyczyny i zakresu i udostępnią aktualizacje w miarę dostępności.

3. 18 sierpnia 2026 21:45 UTCidentified

   Zidentyfikowaliśmy rozwiązanie i rezolucja jest w toku. Następna aktualizacja: Nasze zespoły pracują nad naprawą i udostępnią aktualizacje, jak to możliwe.

4. 18 sierpnia 2026 22:53 UTCmonitoring

   Rozmieściliśmy namiar i monitorujemy rezolucję. Następna aktualizacja: Nasze zespoły monitorują rozdzielczość i udostępniają aktualizacje w miarę dostępności.

5. 18 sierpnia 2026 23:25 UTCresolved

   Wycofanie się zostało rozwiązane, a archiwizacja jest w pełni sprawna. Wpływ: Brak stałego wpływu na użytkownika.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 18 sierpnia 2026 12:08 UTCidentified

   Zidentyfikowaliśmy główną przyczynę problemu w Studio Web, gdzie ekran konfiguracji zasobów do zmiany atrybutów zasobów nie jest wczytywany. Rozstawiamy namiar.

2. 18 sierpnia 2026 13:05 UTCidentified

   Wdrożenie poprawki jest w toku. W miarę postępów wdrożymy dalsze aktualizacje.

3. 18 sierpnia 2026 14:06 UTCidentified

   Ustawienie zostało zweryfikowane i jest realizowane we wszystkich pozostałych regionach. Monitorujemy rozmieszczenie i naprawę. Dziękuję za cierpliwość.

4. 18 sierpnia 2026 17:03 UTCidentified

   Postępuje zgodnie z oczekiwaniami w pozostałych regionach. Kontynuujemy monitorowanie rozmieszczenia. Dziękuję za cierpliwość.

5. 18 sierpnia 2026 18:12 UTCmonitoring

   Postępuje zgodnie z oczekiwaniami w pozostałych regionach. Kontynuujemy monitorowanie rozmieszczenia. Dziękuję za cierpliwość.

6. 18 sierpnia 2026 19:05 UTCresolved

   Rozpoczęcie prac jest zakończone i należy rozwiązać problem.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 18 sierpnia 2026 05:32 UTCinvestigating

   Badamy kwestię wpływającą na rachunki Wspólnoty, w której nowo utworzone podmioty mogą pojawić się w Studio Web przez około godzinę. Nie utracono danych, a istniejące podmioty pozostają bez zmian.

2. 18 sierpnia 2026 06:48 UTCinvestigating

   Nadal badamy tę kwestię i pracujemy nad zidentyfikowaniem przyczyny i przywróceniem normalnego czasu przetwarzania.

3. 18 sierpnia 2026 08:44 UTCinvestigating

   Nadal badamy problem dotykający podzbiór najemców w Europie, Stanach Zjednoczonych i Japonii, gdzie nowo utworzone podmioty mogą zająć więcej czasu niż oczekiwano w Studio Web. Nie utracono danych, a istniejące podmioty pozostają bez zmian.

4. 18 sierpnia 2026 09:37 UTCidentified

   Zidentyfikowaliśmy przyczynę i pracujemy nad rezolucją w sprawie dotyczącej podgrupy najemców w Europie, Stanach Zjednoczonych i Japonii. Dziękuję za cierpliwość.

5. 18 sierpnia 2026 11:19 UTCmonitoring

   Kwestia została złagodzona i oczekujemy, że wkrótce czas przetwarzania powróci do normy. Dokładnie monitorujemy rekonwalescencję. Dziękuję za cierpliwość.

6. 18 sierpnia 2026 11:57 UTCresolved

   Problem został rozwiązany, a czas przetwarzania powrócił do normy. Dziękuję za cierpliwość.

7. 27 sierpnia 2026 03:51 UTCpostmortem

   # # Wpływ na klienta Między 18 sierpnia, 2026 o 5: 11 rano UTC i 18 sierpnia 2026 o 11: 57 rano UTC, nowo utworzone podmioty w podgrupie najemców UiPath Cloud może zająć dłużej niż oczekiwano, aby pojawić się w Studio Web. W momencie dokonywania wstępnej oceny nowo utworzone podmioty pojawiały się z opóźnieniem wynoszącym około jednej godziny. Klienci w Europie, USA i Japonii zostali dotknięci. Utworzenie podmiotów było kontynuowane z powodzeniem, nie utracono danych i istniejące podmioty nie zostały naruszone. # # Root cause Kwestia ta została spowodowana przez niezwykle dużą ilość wniosków o udzielenie pomocy od jednego najemcy. Żądania te wygenerowały więcej zdarzeń niż nasza usługa entity- indexing może przetwarzać w tym samym tempie, tworząc zaległości w kolejce przetwarzania zdarzeń. Ponieważ Studio Web opiera się na tej usłudze, aby wyświetlić nowo utworzone podmioty, nowe podmioty pojawiły się dopiero po przetworzeniu zaległości. # # Detection Problem ten został zidentyfikowany przez nasz zespół inżynieryjny przez podmiot przetwarzający ostrzeżenie o opóźnieniu, a incydent został ogłoszony o 5: 11 rano UTC 18 sierpnia 2026. O 5: 23 nad UTC, analiza potwierdziła, że ostatni przetworzony podmiot był około godziny do tyłu. # # Response O 5: 32 rano UTC, opublikowaliśmy wstępną aktualizację klienta zauważającą opóźnioną widoczność dla nowo utworzonych podmiotów w Studio Web. Do 6: 07 rano UTC, dochodzenie zidentyfikowane niezwykle wysoki ruch tworzenia aktywów od jednego najemcy, a o 7: 03 rano UTC, dostosowaliśmy zasoby bazy danych dla dotkniętej usługi, aby pomóc przetwarzania odzyskać. O 7: 59 UTC, źródło dużej ilości żądań przestało wysyłać prośby, a kolejka zaczęła wysysać. O 9: 59 rano UTC, rozpoczęliśmy proces synchronizacji danych dla poszkodowanego najemcy, a o 10: 31 rano UTC, usunęliśmy problematyczne zdarzenia w kolejce tak normalne przetwarzanie może nadrobić szybciej. Głębokość kolejki spadła z 95000 elementów o 8: 34 rano UTC do 1000 elementów o 11: 44 rano UTC. Incydent został oznaczony na 11: 19 UTC po znacznie odzyskanym przetwarzaniu i rozwiązany o 11: 57 UTC po powrocie czasu przetwarzania do normy. # Follow up Ponowna synchronizacja danych dla poszkodowanego najemcy i monitorowanie spożycia do czasu potwierdzenia zgodności danych lokatora. Ulepszenie obsługi podmiotu w oparciu indeksowania, tak aby zaległości nie nagromadziły się w tym tempie.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 14 sierpnia 2026 21:24 UTCidentified

   We have identified the cause of the degraded performance impacting Orchestrator in US region and are working on mitigation. Impact: Users may experience delayed loads and views on Orchestrator Robot logs. Additional updates will be provided as we move toward resolution.

2. 14 sierpnia 2026 23:22 UTCresolved

   The issue has been resolved and Orchestrator Robot logs performance has returned to expected levels after degraded performance impacted Robot logs to load in US region. Impact: No ongoing user impact.

3. 28 sierpnia 2026 16:55 UTCpostmortem

   ## Customer impact Between August 14, 2026 at 8:54 pm UTC and August 15, 2026 at 2:09 AM UTC, a subset of customers in the US region experienced significant slowness in the Orchestrator Jobs and Logs pages, and robot logs appeared later than expected in the logs view. Performance had substantially recovered by 11:22 PM UTC on August 14, with full recovery confirmed with affected customers at 2:09 AM UTC on August 15. Automation execution was not affected, jobs continued to be scheduled and to run normally throughout. No log data was lost. Logs continued to be recorded and became visible once the system caught up. Requests did not fail, so no errors were surfaced, pages were slow to load and recent activity appeared missing or delayed. No other region was impacted. ## Root cause Orchestrator stores and retrieves robot logs using a dedicated search and storage system. Routine maintenance on that system causes data to be redistributed internally across the cluster. Our analysis indicates that a redistribution larger than anticipated consumed capacity that would otherwise have served customer requests, slowing both the retrieval of existing logs and the processing of new ones. This accounts for the majority, but not the entirety, of the slowdown observed, and analysis of the remaining contributing factor is continuing. Capacity returned to normal without intervention, at which point log visibility and page performance recovered. ## Detection The issue was surfaced through customer reports of slow Jobs and Logs pages in the US region. ## Response We posted a status update confirming that we were investigating degraded Orchestrator performance in the US region. Our engineering team scoped the impact to the US region and narrowed the slowdown to the log storage and search layer. The degradation stemmed from capacity contention that eased as the redistribution completed, and responders monitored the system through recovery. Page performance and log visibility returned to expected levels over the course of the evening, and recovery was subsequently confirmed with affected customers at 2:09 AM UTC on August 15. ## Follow up 1. We are adding monitoring and alerting on the response times customers experience and on the delay between a robot log being generated and becoming visible, so that degradation of this kind is detected proactively. 2. We are documenting an operational procedure that gives our on-call engineers defined steps to reduce customer impact during this class of degradation. 3. We are changing how routine maintenance on the log storage system is scheduled and paced in the US region so that it does not affect customer-facing performance. 4. We are increasing spare capacity in the log storage system so that internal data movement has room to complete without competing with customer requests.

1. 18 sierpnia 2026 10:58 UTCresolved

   Burza żądań na rzadko używanym modelu funkcji w IXP Communications Mining spowodowała ponowną pętlę do zablokowania synchronicznych żądań w szerszym IXP API. Spowodowało to niepowodzenie w przypadku 500 pracowników, którzy byli zajęci długimi wnioskami. Automatyczne skalowanie szybko osiągnęło maksymalną pojemność, a rozdzielczość wykonano tylko poprzez zastosowanie poprawki kodu, która wprowadziła ścisłe przerwy czasowe do wniosku o wpisanie API. Burza na żądanie rozpoczęła się około 15: 10 UTC i wykryła UTC 15: 15 przez automatyczne alarmy. Uchwała została potwierdzona około 18: 15 UTC. Incydent został początkowo błędnie przypisany tylko klientowi, który złożył burzę wniosków, ale później odkryto, że wpłynął na szerszą gamę użytkowników. Całkowity wpływ ograniczony do garstki użytkowników w USA.

2. 18 sierpnia 2026 21:25 UTCpostmortem

   # # Uderzenie klienta W dniu 12 sierpnia 2026 r., między około 15: 10 a 18: 15 UTC, użytkownicy Górnictwa Komunikacyjnego (IXP) w regionie Stanów Zjednoczonych doświadczyli niepowodzeń w zakresie składania wniosków. Incydent był ograniczony do jednego z jednostek rozmieszczenia regionu, gdzie użytkownicy na nim widzieli awarie w wybuchach od pięciu do dziesięciu minut, a do 5- 7% ich wniosków nie powiodło się z 5xx błędów na szczycie. Pomiędzy wybuchem usługi obsługiwanej normalnie, ponownych wniosków ogólnie udało się, i nie utracono danych. # # Root Cause # Burza wniosków do rzadko używanych funkcji API, która oblicza przewidywania uczenia się maszynowego na żądanie zbiega się z powtarzającym się przekwalifikowaniem wymaganego modelu. Każde przekwalifikowanie unieważnione przewidywania cached, zamieniając każde żądanie w wielominutowe obliczenia. API nie wyznaczył terminu na to, jak długo wniosek może czekać na te obliczenia, więc te długie wnioski stopniowo zajmowały wszystkie możliwości przetwarzania wniosków, powodując niepowiązane wnioski, aby nie. Automatyczne skalowanie osiągnęło swoją maksymalną pojemność szybko i nie mogło zrekompensować. # # Detection Automatyczne monitorowanie wykryło awarie o 15: 15 UTC, około 5 minut po zderzeniu i wezwało inżyniera na wezwanie. Incydent został początkowo przypisany wyłącznie klientowi wywołującemu burzę na żądanie, ale raporty klientów i dalsze dochodzenie wykazały, że szerszy zestaw użytkowników został dotknięty podczas wybuchów awarii. # # Response Inżynier on-call namierzył niepowodzenia bez ograniczeń oczekiwania na ścieżce przewidywania na żądanie. Zdolność serwisowa została wielokrotnie przywrócona przez automatyczne zastępowanie instancji, podczas gdy został opracowany kod fix. Rozwiązanie jest ściśle timeout na wniosek wnoszący, więc nie udaje się szybko bez wpływu na inne wnioski, i został wdrożony do dotkniętego regionu około 18: 00 UTC, a rozdzielczość została potwierdzona o 18: 15 UTC. # Follow-Up 1. Surowy timeout i load- shedding fix został stały i zwolniony do wszystkich regionów (ukończone 13 sierpnia 2026). 2. Oszacować ograniczenia dla klienta w zakresie obliczania prognozowania na żądanie, tak aby wykorzystanie jednego klienta nie mogło zniweczyć wspólnego API.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 10 sierpnia 2026 14:11 UTCinvestigating

   Prowadzimy śledztwo w sprawie zdegradowanych wyników mających wpływ na usługi Front- End w porozumieniu w sprawie dokumentów w regionie GXP East US. Impact: Użytkownicy mogą zauważyć timeout podczas dostępu do interfejsu w GXP US. Następna aktualizacja: Dodatkowe aktualizacje będą dostarczane w miarę dostępności dodatkowych informacji.

2. 10 sierpnia 2026 14:25 UTCresolved

   Kwestia ta została rozwiązana, a wyniki usługi Front- End w uzgodnieniu dokumentów powróciły do oczekiwanych poziomów po pogorszeniu się wyników wpłynęły na UI w regionie GXP East US. Wpływ: Brak stałego wpływu na użytkownika.

3. 19 sierpnia 2026 06:14 UTCpostmortem

   # # Wpływ na klienta Między 10 sierpnia 2026 r. o godz. 13: 21 UTC a 10 sierpnia 2026 r. o godz. 14: 03 UTC, podzbiór klientów doświadczył zdegradowanych wyników i przerw czasowych podczas dostępu do interfejsu użytkownika Document Understanding, który zapewnia doświadczenie w czasie design- w regionie USA opóźnionym. Automaty do przetwarzania dokumentów nie zostały naruszone. # # Root cause Podczas ręcznego wdrożenia z istniejącej wcześniej budowy usługi za interfejsem użytkownika Document Understanding do opóźnionego regionu USA, nasz proces wdrożeniowy przeniósł identyfikator wersji dla wdrażanej usługi. Interfejs "Document Understanding" wymaga, aby jego zasoby pomocnicze były dostępne pod tym samym identyfikatorem wersji co uruchomiona usługa. Ponieważ proces wdrożenia zmienił ten identyfikator, interfejs nie mógł zlokalizować wymaganych zasobów, co spowodowało, że stał się niedostępny lub czas. # # Detection Dowiedzieliśmy się o problemie chwilę po zakończeniu rozmieszczenia, poprzez ręczną weryfikację w ramach ręcznej listy kontrolnej rozmieszczenia. Automatyczny alarm został wkrótce uruchomiony o godz. 13: 28 w dniu 10 sierpnia 2026 r. # # Response Po zidentyfikowaniu przyczyny awarii ręcznego rozmieszczania, nasz zespół inżynieryjny zaczął wprowadzać poprawioną aktualizację z wymaganymi zasobami. Jednocześnie zespół operacyjny był zaangażowany w wykonanie ręcznego cofnięcia rozmieszczenia. Powrot został zakończony o 14: 03 UTC, przywracając dostęp do design- time doświadczenia. O 14: 11 UTC, opublikowaliśmy publiczną aktualizację statusu wskazującą zdegradowaną wydajność i możliwe przerwy czasowe w interfejsie użytkownika Document Understanding dla opóźnionego regionu USA. Do 14: 15 UTC poprawiona aktualizacja została zakończona, a interfejs został potwierdzony poprawną nową wersją i działa. O 14: 25 UTC, incydent został oznaczony rozwiązany i strona stanu publicznego została zaktualizowana w celu potwierdzenia, że działanie interfejsu Document Understanding powróciło do oczekiwanych poziomów. # Follow up 1. Zmniejszamy czas potrzebny na przywrócenie poprzedniej wersji usługi, tak aby odzyskanie z nieudanego wdrożenia było szybsze. 2. Ulepszamy proces ręcznego wdrażania, aby zapobiec przyszłej sytuacji, zatwierdzając istnienie wymaganych zasobów jako warunek wstępny.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 8 sierpnia 2026 11:54 UTCidentified

   We have identified the cause of the outage impacting Uipath Apps is facing outage in Delayed US region and are working on a fix. Impact: Users may continue to be unable to access Uipath Apps and solutions dependent on Uipath Apps. Team is working on service restoration.

2. 8 sierpnia 2026 13:01 UTCidentified

   Team is working on service restoration. We will update the status once mitigation is completed.

3. 8 sierpnia 2026 14:14 UTCidentified

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

4. 8 sierpnia 2026 15:30 UTCidentified

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

5. 8 sierpnia 2026 15:32 UTCmonitoring

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

6. 8 sierpnia 2026 16:01 UTCresolved

   The mitigation has remained stable, and performance has returned to expected levels. We have confirmed service restoration for UiPath Apps in the Delayed US region and are marking this incident as resolved.

7. 12 sierpnia 2026 10:14 UTCpostmortem

   ## Customer impact Between 11:20 am UTC and 2:54 pm UTC on August 8, 2026, a subset of customers in the Delayed US region experienced failures accessing UiPath Apps and solutions that depend on UiPath Apps. Customers may have seen UiPath Apps unavailable or intermittent request failures. The impact lasted approximately 3 hours and 34 minutes. ## Root cause The incident was caused by database connection saturation following scheduled maintenance performed by our database provider. As application services scaled up, they created additional database connections, which caused new connection attempts to fail and resulted in connection reset errors in UiPath Apps. ## Detection Automated alerts detected the issue at 11:24 am UTC on August 8, 2026. Application telemetry showed failures beginning at approximately 11:20 am UTC. ## Response At 11:00 am UTC, scheduled maintenance began automatically. At 11:20 am UTC, requests began failing. At 11:24 am UTC, automated alerts were triggered, and the team began investigating. At 12:24 pm UTC, database capacity was scaled up as a mitigation. At 1:13 pm UTC, application services were restarted to reduce saturated connection usage and refresh database connections. Connection levels remained elevated, and the database automatically scaled at 1:22 pm UTC and at 2:36 pm UTC. Following these mitigation efforts, request failures stopped at 2:54 pm UTC. At 3:33 pm UTC, the mitigation was confirmed to be stable, and performance was improving. Full recovery was confirmed at 4:01 pm UTC after performance returned to expected levels. ## Follow up 1. Obtain and review the database provider's root cause analysis explaining what caused the connection issue following their maintenance activity. 2. Implement an application-side limit on database connection creation to prevent connection saturation. 3. We are reviewing the automatic scaling behavior that amplified connection volume during the incident and address any contributing factors.

1. 6 sierpnia 2026 21:14 UTCresolved

   Between 06-08-2026 10:00 UTC and 06-08-2026 13:00 UTC, some organizations in the US region were unable to complete document ingestion. A small number of search requests in the same region were also slow or timed out. The issue was caused by a capacity constraint affecting ingestion processing in US. Normal performance was restored at 13:00 UTC. We have monitored the affected environments since recovery and confirm the issue is fully mitigated. Ingestion requests that failed during this window were not retried automatically and will need to be re-submitted. No action is required for search.

2. 13 sierpnia 2026 15:12 UTCpostmortem

   ## Customer impact Between August 6, 2026 at 10:00 am UTC and 1:00 pm UTC, some organizations in the US region were unable to complete document ingestion in **UiPath Context Grounding**. A small number of search requests in the same region were also slow or timed out. **Action required:** please re-submit the affected ingestion requests. Ingestion retries a failing request automatically for a limited number of attempts. Once those attempts are exhausted the request is marked failed and is not retried again, so affected documents will not appear in your index until the request is submitted again. Failed requests are listed in the ingestion history for each index. No action is required for search. Those requests were affected only while the issue was ongoing, and subsequent searches completed normally. --- ## Root cause A sudden increase in concurrent document ingestion triggered a high number of simultaneous document validation steps, which created a capacity bottleneck on the underlying infrastructure resource beyond its scaling capacity. Once that resource was saturated, ingestion operations began exceeding their time limits and failing. Automatic retries of the failed operations added further load, which sustained the condition. Search requests served by the same resource were delayed behind the same contention. --- ## Detection Automated alerts were flagged as the condition developed, and an automated infrastructure resource capacity alert triggered at 10:37 am UTC brought it to the team's attention. --- ## Response - **10:03 am UTC** — Automated low severity alerts started coming in. - **10:37 am UTC** — Automated alert for resource capacity issue paged the team. - **12:23 pm UTC** — As a mitigation step the impacted resource's capacity was increased. - **12:57 pm UTC** — Ingestion and search operations stopped failing and response times returned to normal. --- ## Follow-up - **The fix is deployed.** The validation step has been reimplemented to enforce the same limits at a small fraction of the previous cost, so this level of concurrent ingestion now sits well within available capacity. It was released to the affected US region on August 7, ahead of schedule, and reaches all remaining regions by early September. - **We are improving how quickly we detect issues like this.** We are adding monitoring that tracks whether document ingestion is completing successfully for customers, so problems are identified and acted on directly rather than inferred from underlying system alerts. This will be in place across all regions by the end of August.