История сбоев Uipath

1. 3 сентября 2026 г. в 15:34 UTCinvestigating

   В настоящее время мы инвестируем в эту проблему

2. 3 сентября 2026 г. в 15:39 UTCidentified

   Этот вопрос был выявлен, и для его решения были приняты соответствующие меры по смягчению последствий.

3. 3 сентября 2026 г. в 15:47 UTCmonitoring

   Вопрос успешно решен, служба полностью восстановлена. В это время сервис работает в обычном режиме.

4. 3 сентября 2026 г. в 16:17 UTCresolved

   Вопрос успешно решен, служба полностью восстановлена. В это время сервис работает в обычном режиме.

Автоматический перевод официального обновления инцидента.

1. 4 сентября 2026 г. в 17:48 UTCresolved

   Панель инструментов Insights в Looker столкнулась с проблемой, которая помешала последним запускам Maestro появиться на приборной панели. Влиятельные регионы: США, SEA, IND, CA, AUE, JP, Великобритания Сроки инцидентов Начало: 2 сентября 2026 в 20:00:00 UTC Решено: 4 сентября 2026 года в 16:30:00 UTC Проблема в настоящее время решена, и приборная панель Insights отображает последние данные запуска Maestro.

Автоматический перевод официального обновления инцидента.

1. 1 сентября 2026 г. в 13:49 UTCinvestigating

   Мы расследуем сообщения о ухудшении производительности, влияющей на оцифровку и извлечение для понимания документов и IXP в США. Влияние: пользователи могут испытывать медлительность и неудачную работу с пониманием документов. Наши команды работают над выявлением причины и будут делиться более подробной информацией по мере продвижения расследования.

2. 1 сентября 2026 г. в 14:07 UTCmonitoring

   Мы определили проблему и применили смягчение. Услуги возвращаются в здоровое состояние, и мы следим за ними.

3. 1 сентября 2026 г. в 15:06 UTCresolved

   Этот вопрос был полностью решен, и услуги сейчас стабильны. В ближайшее время мы опубликуем более подробную информацию об инциденте на странице статуса.

Автоматический перевод официального обновления инцидента.

1. 31 августа 2026 г. в 16:55 UTCinvestigating

   В настоящее время мы расследуем этот вопрос.

2. 31 августа 2026 г. в 17:07 UTCidentified

   Мы определили проблему и внедрили необходимое исправление

3. 31 августа 2026 г. в 18:24 UTCmonitoring

   Проблема была смягчена, и служба в настоящее время работает. Мы продолжим внимательно следить за состоянием сервиса и при необходимости предпримем дальнейшие действия.

4. 31 августа 2026 г. в 19:39 UTCresolved

   Проблема была смягчена, и служба в настоящее время работает. Мы продолжим внимательно следить за состоянием сервиса и при необходимости предпримем дальнейшие действия.

Автоматический перевод официального обновления инцидента.

1. 28 августа 2026 г. в 15:41 UTCidentified

   Проблема была выявлена, и команда активно работает над развертыванием исправления. Мы ожидаем, что развертывание начнется в ближайшие часы.

2. 28 августа 2026 г. в 17:27 UTCmonitoring

   Мы определили первопричину ухудшения производительности, и мы находимся в процессе развертывания исправления в ближайшие часы. Это влияет на связанные запросы, когда пользователь не имеет доступа к исходной папке. Поверхность API не подвержена влиянию. Экспорт через CSV можно использовать как обходной путь. По мере продвижения к разрешению будут предоставляться дополнительные обновления.

3. 28 августа 2026 г. в 17:39 UTCidentified

   Мы определили первопричину ухудшения производительности, и мы находимся в процессе развертывания исправления в ближайшие часы. Это влияет на связанные запросы, когда пользователь не имеет доступа к исходной папке. Поверхность API не подвержена влиянию. Экспорт через CSV можно использовать как обходной путь. По мере продвижения к разрешению будут предоставляться дополнительные обновления.

4. 28 августа 2026 г. в 20:00 UTCidentified

   В настоящее время применяется исправление. Мы предоставим еще одно обновление вскоре после завершения развертывания во всех пострадавших регионах.

5. 28 августа 2026 г. в 22:57 UTCresolved

   Решение было успешно развернуто во всех регионах, и мы подтвердили, что проблема решена. Сервис работает, как и ожидалось.

6. 3 сентября 2026 г. в 08:49 UTCpostmortem

   ##Воздействие на клиента Между 28 августа 2026 года в 3:23 вечера по UTC и 28 августа 2026 года в 10:57 вечера по UTC подмножество клиентов испытывало ошибки при открытии панелей деталей очередей в Orchestrator. Поврежденный путь возвращал страницу 404 для очередей LINKED, когда пользователь не имел доступа к исходной папке, в которой были созданы элементы. Воздействие затронуло только взаимодействие пользовательского интерфейса Orchestrator, и оно охватило все регионы, работающие с затронутой версией программного обеспечения. Доступ к интерфейсу прикладного программирования Orchestrator не был затронут, и экспорт данных очередей в CSV был доступен в качестве обходного пути. Общая продолжительность составила около 7 часов. ##Коренная причина Инцидент был вызван регрессией в пользовательском интерфейсе Orchestrator для связанных очередей, доступных из других папок. Регрессия неправильно обрабатывала поток связанных с очередями деталей, когда запрашивающему пользователю не хватало доступа к исходной папке, что приводило к тому, что панель деталей очередей направлялась на страницу 404 вместо отображения ожидаемой информации. ## Обнаружение Проблема была обнаружена с помощью автоматического оповещения об инциденте для фронт-энда Orchestrator 28 августа 2026 года в 3:23 вечера UTC. ## Ответить В 3:31 вечера по Гринвичу 28 августа 2026 года наша команда инженеров описала проблему как то, что клиенты не могут получить доступ к панелям деталей очередей из-за регрессии. В 3:41 вечера UTC публичное обновление статуса подтвердило, что первопричина была идентифицирована, что было развернуто исправление и что доступ к интерфейсу прикладного программирования не был затронут. В 5:27 вечера UTC, область была сужена до связанных очередей, где пользователь не имел доступа к исходной папке. В 5:29 вечера UTC команда определила, что первоначальное исправление не полностью устранило затронутый сценарий, и было разработано исправленное исправление. В 5:30 вечера UTC был воспроизведен затронутый сценарий и исправленное исправление было подтверждено локально. В 5:39 вечера UTC обновление страницы статуса документировало экспорт CSV в качестве обходного пути. Развертывание исправленного исправления продолжалось в пострадавших регионах. В 10:50 вечера UTC, исправление было подтверждено развернуто везде. В 10:57 вечера UTC инцидент был помечен как устраненный, и страница статуса была обновлена, чтобы подтвердить, что служба работает так, как ожидалось. ##Продолжение Официальные последующие действия отслеживаются в рамках процесса рассмотрения после инцидента, начатого в резолюции. ## Действия Расширение наших автоматизированных тестовых случаев, чтобы включить этот сценарий и другие подобные сценарии, связанные со связанными объектами или сценариями кросс-папки. Обеспечение безопасного отключения любых изменений с помощью флага для более быстрого времени отклика.

Автоматический перевод официального обновления инцидента.

1. 27 августа 2026 г. в 17:16 UTCinvestigating

   Мы расследуем сообщения о пропавших роботах в регионе США. Наши команды работают над выявлением причины и будут делиться более подробной информацией по мере продвижения расследования.

2. 27 августа 2026 г. в 18:53 UTCidentified

   Мы определили, что проглатывание журналов роботов было отложено. Журналы роботов догоняют живые данные, и мы отслеживаем восстановление.

3. 27 августа 2026 г. в 20:31 UTCmonitoring

   В настоящее время журналы заполняются в режиме реального времени, и мы продолжим мониторинг приложения.

4. 27 августа 2026 г. в 21:57 UTCresolved

   Проблема решена, и журналы заполняются, как и ожидалось.

Автоматический перевод официального обновления инцидента.

1. 25 августа 2026 г. в 09:41 UTCidentified

   Мы выявили проблему, затрагивающую функцию развертывания решений в Studio Web в регионе Японии, где развертывание решений может привести к сбою. Было подготовлено исправление, которое будет развернуто в ближайшее время. Мы предоставим дополнительные обновления по мере поступления дополнительной информации.

2. 25 августа 2026 г. в 09:47 UTCmonitoring

   Решение было успешно развернуто в регионе Японии, и проблема была смягчена. Мы внимательно следим за сервисом, чтобы убедиться, что развертывание решений продолжает работать так, как ожидалось, и предоставит дополнительные обновления по мере необходимости.

3. 25 августа 2026 г. в 10:12 UTCresolved

   Проблема решена, и развертывание решений в Studio Web работает, как и ожидалось, в регионе Японии. Дальнейшего воздействия не наблюдалось.

Автоматический перевод официального обновления инцидента.

1. 25 августа 2026 г. в 03:58 UTCinvestigating

   Мы расследуем проблему, затрагивающую клиентов, использующих Insights в регионе Сингапура, где приборные панели могут не загружать и отображать ошибки тайм-аута. Наши команды работают над выявлением первопричины и предоставят дополнительные обновления по мере поступления дополнительной информации.

2. 25 августа 2026 г. в 04:37 UTCmonitoring

   Проблема была смягчена, и мы внимательно следим за службой Insights в регионе Сингапура, чтобы обеспечить дальнейшую загрузку приборных панелей.

3. 25 августа 2026 г. в 04:53 UTCresolved

   Проблема решена, и служба Insights в Сингапуре работает, как и ожидалось. Дальнейшего воздействия не наблюдалось.

4. 4 сентября 2026 г. в 11:46 UTCpostmortem

   ##Воздействие на клиента В период с 25 августа 2026 года в 3:42 утра по UTC и 25 августа 2026 года в 4:53 утра по UTC клиенты, использующие Insights в Сингапурском регионе, испытывали сбои при загрузке приборных панелей Insights. Пострадавшие пользователи видели, что страницы панели инструментов не загружаются или не загружаются, а ошибки сервера наблюдались для соответствующих запросов на обслуживание. Основное влияние оказал доступ к приборной панели Insights, включая диаграммы и оповещения. Связанный бэкэнд-сервис также возвращал ошибки сервера во время инцидента, но доступ к приборной панели восстановился до окончательного разрешения. ##Коренная причина Инцидент был связан с региональным сбоем службы Microsoft в Сингапуре, который затронул инфраструктуру, используемую службой Insights. Во время сбоя служба Insights не смогла надежно обслуживать запросы на панели инструментов, что привело к тайм-ауту запросов и ошибкам сервера. Никаких изменений с нашей стороны не произошло. Сервис восстановился после того, как было решено региональное нарушение Microsoft, и Microsoft впоследствии сообщила о проблеме регионального обслуживания в Сингапуре на своей странице статуса. Microsoft запросила официальный анализ первопричин, чтобы подтвердить конкретный механизм отказа и определить любые дополнительные меры по предотвращению или смягчению последствий. ## Обнаружение Автоматический мониторинг состояния здоровья для службы Insights обнаружил проблему в 25 августа 2026 года в 3:42 утра по UTC. Влияние на клиента было подтверждено на мосту вскоре после обнаружения. ## Ответить 25 августа 2026 года в 3:58 утра UTC мы опубликовали публичное обновление статуса, отметив, что панели мониторинга Insights в регионе Сингапура могут не загружать и отображать ошибки тайм-аута. Во время ответа наша команда инженеров проверила ошибки сервера в автоматическом мониторинге, попыталась получить доступ к сервисной диагностике и начала процедуру восстановления базовой инфраструктуры. 25 августа 2026 года в 4:01 UTC служба Insights восстановилась во время процедуры восстановления, и загрузка панели приборов была проверена на нескольких тестовых учетных записях. 25 августа 2026 года в 4:37 утра UTC мы перенесли инцидент на мониторинг после подтверждения успешно загруженных приборных панелей. Соответствующий бэкэнд-сервис восстановился в 25 августа 2026 года в 4:49 утра по UTC, а инцидент был отмечен урегулированным в 25 августа 2026 года в 4:53 утра по UTC. ##Продолжение 1. запросить у Microsoft анализ первопричин регионального сбоя в Сингапуре, затрагивающего проблему загрузки информационных панелей.

Автоматический перевод официального обновления инцидента.

1. 25 августа 2026 г. в 03:44 UTCinvestigating

   Мы расследуем проблему, затрагивающую клиентов, использующих расширенную функциональность OCR в сервисе Document Understanding в Сингапуре. Наши команды работают над выявлением первопричины и предоставят дополнительные обновления по мере поступления дополнительной информации.

2. 25 августа 2026 г. в 04:04 UTCmonitoring

   Проблема была смягчена, и мы внимательно следим за службой, чтобы она продолжала работать, как ожидалось. Мы предоставим дополнительные обновления по мере поступления дополнительной информации.

3. 25 августа 2026 г. в 04:59 UTCresolved

   Вопрос решен, и служба работает, как и ожидалось. Дальнейшего воздействия не наблюдалось.

4. 27 августа 2026 г. в 03:42 UTCpostmortem

   ##Воздействие на клиента 25 августа 2026 года расширенные запросы OCR в сервисе Document Understanding провалились с 500 кодами статуса в регионе Сингапура примерно на 33 минуты, между 03:08 и 03:41 UTC. Причиной стало нарушение работы региональных служб Microsoft в Сингапуре. Все остальные функции Document Understanding не были затронуты, и ни один другой регион не был затронут. ##Коренная причина Провал был связан с региональным сбоем службы Microsoft в Сингапуре, затрагивающим ресурсы, используемые расширенными возможностями OCR. Никаких изменений с нашей стороны не произошло, и Microsoft впоследствии обновила свою страницу статуса, чтобы отразить региональную проблему Сингапура. От Microsoft был запрошен формальный анализ первопричин. ## Обнаружение Автоматизированное предупреждение для службы «Понимание документов» было выпущено 25 августа 2026 года в 3:13 утра по UTC. Предупреждение было быстро подтверждено, и инцидент был объявлен влияющим на клиента в течение нескольких минут. ## Ответить Инженер по вызову оценил воздействие на регион Сингапура. Респонденты исключили недавнее обновление службы в качестве причины, поскольку то же самое обновление было развернуто в других регионах без сопоставимого воздействия, что указывало на сбой региональной зависимости за пределами нашей инфраструктуры. Поскольку сбой произошел в вышестоящем сервисе Microsoft, никаких смягчающих действий на стороне UiPath не было доступно. Запросы снова стали успешными в 03:41 по мере восстановления зависимости от Microsoft. Респонденты держали инцидент открытым для проверки устойчивого восстановления: десять минут чистого трафика были подтверждены в 03:51 UTC, инцидент переместился в Мониторинг в 04:04 UTC, и он был решен в 04:59 UTC после продолжающейся стабильности без дальнейших сбоев. ##Продолжение 1. запросил у Microsoft анализ первопричин регионального сбоя в Сингапуре, затрагивающего расширенные OCR-зависимости, включая то, как можно предотвратить рецидив.

Автоматический перевод официального обновления инцидента.

1. 24 августа 2026 г. в 10:43 UTCidentified

   Мы определили причину проблемы, затрагивающей небольшое количество клиентов, использующих приложения UiPath, созданные с помощью веб-сервиса Studio в нескольких регионах. Наши команды готовы к исправлению, и развертывание начнется в пострадавших регионах. Мы будем продолжать следить за развертыванием и предоставлять дальнейшие обновления по мере вступления исправления в силу.

2. 24 августа 2026 г. в 11:30 UTCmonitoring

   Решение было успешно развернуто во всех пострадавших регионах, и проблема была смягчена. Мы внимательно следим за сервисом, чтобы убедиться, что исправление продолжает работать так, как ожидалось, и предоставит дополнительные обновления по мере необходимости.

3. 24 августа 2026 г. в 11:55 UTCresolved

   Вопрос решен, и служба работает, как и ожидалось. Дальнейшего воздействия не наблюдалось.

4. 1 сентября 2026 г. в 11:47 UTCpostmortem

   ##Воздействие на клиента Между 19 августа 2026 года в 2:33 вечера по UTC и 24 августа 2026 года в 11:30 утра по UTC подмножество клиентов не смогли загрузить проекты UiPath Apps, написанные из Studio Web. Пострадавшие клиенты испытывали полную недоступность проектов Apps, а не медлительность или ухудшенную производительность. Влияние было ограничено небольшим набором клиентов, чей сервис Apps был размещен в регионе Японии. Общая продолжительность воздействия на клиента составила примерно 4 дня и 21 час. ##Коренная причина Основной причиной было несоответствие между Studio Web и UiPath Apps. 19 августа 2026 года Studio Web получила запланированное обновление в регионе ЕС, которое включало обновление фреймворка. Соответствующее обновление UiPath Apps, содержащее обновление фреймворка, еще не было развернуто в Японии. Более раннее обновление Apps, которое уже было совместимо с новой рамочной версией, было развернуто во всех регионах, кроме Японии, где развертывание было отложено по несвязанным причинам. В результате в японском регионе все еще работает старая версия Apps, которая не совместима с обновленной Studio Web. ## Обнаружение О проблеме сообщил клиент через свою команду учетных записей UiPath 24 августа 2026 года в 9:36 утра по UTC. Инцидент был открыт в 10:21 утра по Гринвичу, и в течение минуты был объявлен инцидент на странице общественного статуса. Существующий автоматизированный мониторинг не выявил проблему, поскольку он проверяет согласованные комбинации развертывания; улучшение обнаружения для смешанных конфигураций является частью нашего плана последующих действий. ## Ответить В течение нескольких минут после открытия инцидента мы определили несоответствие развертывания в качестве основной причины и решили ускорить развертывание соответствующего обновления приложений UiPath для всех затронутых регионов, согласовав приложения с веб-версией Studio, уже обслуживаемой для пострадавших клиентов. В 10:43 утра UTC мы опубликовали обновление общественного статуса, подтверждающее, что причина была идентифицирована и что исправление развертывается. В 10:52 по Гринвичу развертывание в остальных регионах уже было завершено. В 11:30 утра по Гринвичу мы подтвердили, что исправление было развернуто во всех пострадавших регионах, и отметили, что инцидент смягчился. В 11:55 утра по Гринвичу, после того, как мониторинг не показал дальнейшего воздействия, инцидент был отмечен как устраненный. ##Продолжение 1. Добавить автоматическое оповещение о производственной телеметрии для обнаружения сбоев загрузки приложений, связанных с обслуживаемой версией Studio Web. 2. Реализуйте синтетический мониторинг, который регулярно загружает проект Apps, созданный в Studio Web, в репрезентативные конфигурации клиентов и оповещения о сбое. 3. Настройка последовательности выпуска для тесно связанных между собой Studio Web и Apps изменяется таким образом, чтобы зависимые обновления приложений были полностью развернуты во всех регионах до того, как новый опыт Studio Web достигнет трафика клиентов.

Автоматический перевод официального обновления инцидента.

1. 21 августа 2026 г. в 12:37 UTCmonitoring

   В США было реализовано исправление проблемы, влияющей на классификацию и извлечение документов для понимания документов, и в настоящее время мы отслеживаем результаты.

2. 21 августа 2026 г. в 13:36 UTCresolved

   Вопрос о классификации и извлечении документов для понимания документов в регионе США решен. После периода мониторинга обслуживание подтверждается здоровым и работающим нормально.

3. 27 августа 2026 г. в 03:46 UTCpostmortem

   ##Воздействие на клиента Между 21 августа 2026 года в 11:05 утра по UTC и 21 августа 2026 года в 12:18 вечера по UTC, подмножество клиентов испытали неудачные операции по пониманию документов, включая классификацию документов, извлечение и оцифровку. Предполагаемая продолжительность частичного отключения составила 48 минут. Влияние было ограничено клиентами, использующими документооборот в регионе США. ##Коренная причина Инцидент был вызван отказоустойчивой конфигурацией базы данных Document Understanding, входящей в неисправное состояние во время операции по масштабированию базы данных. Масштабирование началось после того, как база данных приблизилась к пределу хранения. Во время операции вторичная база данных не могла быть масштабирована, попытка удаления из конфигурации отказоустойчивости не удалась, и поставщику платформы базы данных пришлось разорвать линию репликации. Это оставило конфигурацию отказоустойчивости во временном недоступном состоянии, в результате чего службы хранения и выполнения, зависящие от этой базы данных, отказывались от запросов. ## Обнаружение Инцидент был обнаружен с помощью автоматического оповещения для служб по пониманию документов, которое было признано 21 августа 2026 года в 12:10 вечера по UTC. ## Ответить До того, как было объявлено об инциденте, повлиявшем на клиента, было завершено расширение первичной базы данных и была оказана поддержка со стороны поставщика платформы баз данных в связи с проблемой вторичной базы данных. После того, как конфигурация отказоустойчивости была нарушена, мы исследовали перенаправление соединения службы, но не смогли определить безопасный, немедленный путь для этого, учитывая текущую конфигурацию службы. Сервис был восстановлен путем удаления нездоровой вторичной базы данных и восстановления конфигурации отказоустойчивости. К 21 августа 2026 года в 12:37 вечера UTC исправление было реализовано и мониторинг продолжался. В 1:36 вечера UTC мониторинг подтвердил, что служба была здорова, и инцидент был отмечен как устраненный. ##Продолжение 1. запросить у поставщика платформы баз данных анализ первопричин, чтобы определить, почему вторичная база данных не может быть масштабирована и почему восстановление конфигурации отказоустойчивости требует прерывания репликации. 2.Обновить пороги оповещения о хранении данных и маршрутизацию, чтобы оповещения назначались и действовали ранее, включая предупреждение о меньшей степени тяжести при использовании 75% и оповещение о более высокой степени тяжести при использовании 85%.

Автоматический перевод официального обновления инцидента.

1. 19 августа 2026 г. в 16:34 UTCinvestigating

   Мы расследуем проблему, которая может затронуть некоторых клиентов, использующих Claude Sonnet 4.6 в Агентах в регионе США. Наша инженерная команда активно работает над пониманием проблемы и будет делиться дальнейшими обновлениями по мере поступления дополнительной информации.

2. 19 августа 2026 г. в 16:40 UTCmonitoring

   Мы смягчили этот вопрос. Наша инженерная команда активно работает утром и будет делиться дальнейшими обновлениями по мере поступления дополнительной информации.

3. 19 августа 2026 г. в 16:42 UTCmonitoring

   Мы смягчили этот вопрос. Наша инженерная команда активно отслеживает и будет делиться дальнейшими обновлениями по мере поступления дополнительной информации.

4. 19 августа 2026 г. в 16:55 UTCresolved

   Вопрос решен.

5. 31 августа 2026 г. в 12:41 UTCpostmortem

   ##Влияние на клиента Между 19 августа 2026 года в 1:36 вечера по UTC и 19 августа 2026 года в 3:53 вечера по UTC подмножество клиентов получили ошибки при использовании Claude Sonnet 4.6 в Agents. Удар длился примерно 2 часа 17 минут. Это повлияло на клиентов, использующих агентов в регионе США. Также наблюдались ошибки для Claude Opus 4.6 и Claude Opus 4.5, которые используются при меньшем объеме. - ##Коренная причина В рамках запланированной миграции инфраструктуры мы переместили сервис платформы, который направляет типовые запросы на Агентов, в новую систему доставки конфигурации. В новом источнике конфигурации отсутствовали записи маршрутизации для трех моделей Claude — Claude Sonnet 4.6, Claude Opus 4.6 и Claude Opus 4.5. Без этих записей сервис не смог бы решить действительный пункт назначения для запросов к этим моделям и отклонил их с ошибками. Другие модели не пострадали и продолжали нормально работать. - ## Обнаружение Проблема была обнаружена в результате эскалации клиентов 19 августа 2026 года в 2:55 вечера по UTC — примерно через 1 час и 19 минут после первого затронутого запроса. Наша инженерная команда разобрала проблему с конкретными моделями Клода и начала расследование. Общественное общение началось в 3:08 вечера UTC. Наш мониторинг оповещений основан на совокупных показателях ошибок. Хотя почти все запросы к трем затронутым моделям не удовлетворялись, эти модели представляли собой небольшую долю общего трафика в регионе, поэтому совокупный сигнал не пересекал наши пороги оповещения, и проблема не была поднята автоматически. Это пробел в выявлении, который рассматривается в последующих мерах. - ## Ответить В 3:25 вечера UTC в качестве причины был идентифицирован неполный источник конфигурации, и было начато исправление. В 3:47 вечера UTC развертывание исправления продолжалось, и служба активно контролировалась по мере развертывания изменения. К 3:59 вечера UTC журналы обслуживания подтвердили, что проблема была смягчена, а в 4:00 вечера UTC процент отказов был подтвержден на уровне 0%. Инцидент был отмечен как смягченный в 4:40 вечера по Гринвичу, а полное разрешение было объявлено в 4:55 вечера по Гринвичу после непрерывного мониторинга и подтверждения клиентов о том, что служба работает, как ожидалось. - ##Поддержка Миграция инфраструктуры была завершена во всех регионах, и конфигурация маршрутизации теперь исходит из одного источника, устраняя несоответствие, которое вызвало этот инцидент, чтобы он не мог повториться. Автоматизированные проверки вводятся для непрерывной проверки каждой поддерживаемой модели в каждом регионе, поэтому недоступная модель обнаруживается и немедленно оповещается, в том числе в регионах с более низким трафиком.

Автоматический перевод официального обновления инцидента.

1. 18 августа 2026 г. в 17:54 UTCinvestigating

   Мы расследуем сообщения о сбоях в оценке экспрессии, связанных с параметрами вывода задач HITL для Asgentic Orchestratron в сообществах пользователей в Европе. Влияние: пользователи не могут выполнять задачи HITL Наши команды работают над тем, чтобы понять причину и масштаб, и будут делиться обновлениями по мере их доступности.

2. 18 августа 2026 г. в 20:31 UTCidentified

   Мы определили причину сбоя в оценках экспрессии, связанных с параметрами вывода задач HITL для Agentic Orchestration в сообществах пользователей в Европе. Влияние: пользователи будут испытывать сбои, когда у них есть выражения, использующие параметр вывода задачи HITL. Наши команды работают над тем, чтобы понять причину и масштаб, и будут делиться обновлениями по мере их доступности.

3. 18 августа 2026 г. в 21:45 UTCidentified

   Мы определили исправление, и резолюция находится в стадии разработки. Следующее обновление: наши команды работают над исправлением и будут делиться обновлениями по мере их доступности.

4. 18 августа 2026 г. в 22:53 UTCmonitoring

   Мы внедрили исправление и следим за резолюцией. Следующее обновление: наши команды следят за разрешением и будут делиться обновлениями по мере их доступности.

5. 18 августа 2026 г. в 23:25 UTCresolved

   Отключение было устранено, и Agentic Orchestration полностью работает. Влияние: нет постоянного воздействия пользователя.

Автоматический перевод официального обновления инцидента.

1. 18 августа 2026 г. в 12:08 UTCidentified

   Мы определили первопричину проблемы в Studio Web, где экран конфигурации ресурса для изменения атрибутов ресурса не загружается. Мы внедряем исправление.

2. 18 августа 2026 г. в 13:05 UTCidentified

   Развертывание исправления продолжается. Мы предоставим дополнительные обновления по мере развертывания.

3. 18 августа 2026 г. в 14:06 UTCidentified

   Это исправление было проверено и внедряется во всех оставшихся регионах. Мы отслеживаем развертывание и восстановление. Спасибо за ваше терпение.

4. 18 августа 2026 г. в 17:03 UTCidentified

   В остальных регионах развертывание продолжается, как и ожидалось. Мы продолжаем следить за развертыванием. Спасибо за ваше терпение.

5. 18 августа 2026 г. в 18:12 UTCmonitoring

   В остальных регионах развертывание продолжается, как и ожидалось. Мы продолжаем следить за развертыванием. Спасибо за ваше терпение.

6. 18 августа 2026 г. в 19:05 UTCresolved

   Развертывание завершено и вопрос должен быть решен.

Автоматический перевод официального обновления инцидента.

1. 18 августа 2026 г. в 05:32 UTCinvestigating

   Мы расследуем проблему, затрагивающую учетные записи сообщества, где вновь созданным организациям может потребоваться около часа для появления в Studio Web. Данные не теряются, а существующие объекты не затрагиваются.

2. 18 августа 2026 г. в 06:48 UTCinvestigating

   Мы продолжаем исследовать проблему и работаем над выявлением первопричины и восстановлением нормального времени обработки.

3. 18 августа 2026 г. в 08:44 UTCinvestigating

   Мы продолжаем исследовать проблему, затрагивающую подгруппу арендаторов в Европе, США и Японии, где вновь созданные организации могут занять больше времени, чем ожидалось. Данные не теряются, а существующие объекты не затрагиваются.

4. 18 августа 2026 г. в 09:37 UTCidentified

   Мы определили причину и работаем над решением проблемы, затрагивающей подгруппу арендаторов в Европе, США и Японии. Спасибо за ваше терпение.

5. 18 августа 2026 г. в 11:19 UTCmonitoring

   Проблема была смягчена, и мы ожидаем, что время обработки скоро вернется к норме. Мы внимательно следим за восстановлением. Спасибо за ваше терпение.

6. 18 августа 2026 г. в 11:57 UTCresolved

   Проблема решена, и время обработки вернулось к норме. Спасибо за ваше терпение.

7. 27 августа 2026 г. в 03:51 UTCpostmortem

   ##Воздействие на клиента Между 18 августа 2026 года в 5:11 утра по UTC и 18 августа 2026 года в 11:57 утра по UTC, вновь созданные объекты в подмножестве арендаторов UiPath Cloud могут занять больше времени, чем ожидалось. На момент первоначальной оценки вновь созданные организации появлялись примерно с часовой задержкой. Пострадали клиенты в Европе, США и Японии. Само создание организации продолжалось успешно, никакие данные не были потеряны, а существующие организации не пострадали. ##Коренная причина Проблема была вызвана необычайно большим объемом запросов на создание активов от одного арендатора. Эти запросы генерировали больше событий, чем наш серверный сервис индексирования сущности мог обрабатывать с той же скоростью, создавая отставание в очереди обработки событий. Поскольку Studio Web использует эту услугу для отображения вновь созданных объектов, новые объекты появились только после обработки отставания. ## Обнаружение Проблема была определена нашей инженерной командой оповещением о задержке, и инцидент был объявлен в 5:11 утра 18 августа 2026 года. К 5:23 утра UTC, анализ подтвердил, что последний обработанный объект был примерно на час позади. ## Ответить В 5:32 утра UTC мы опубликовали первоначальное обновление для клиентов, отметив задержку видимости для вновь созданных объектов в Studio Web. К 6:07 утра по UTC расследование выявило необычно высокий трафик на создание активов от одного арендатора, а в 7:03 утра по UTC мы скорректировали ресурсы базы данных для пострадавшего сервиса, чтобы помочь обработке восстановиться. В 7:59 утра UTC источник большого объема запросов перестал отправлять запросы, и очередь начала стекать. В 9:59 утра UTC мы начали процесс синхронизации данных для пострадавшего арендатора, а в 10:31 утра UTC мы удалили проблемные события в очереди, чтобы нормальная обработка могла быстрее наверстать упущенное. Глубина очереди снизилась с 95 000 пунктов в 8:34 утра по UTC до 1000 пунктов в 11:44 утра по UTC. Инцидент был отмечен как смягченный в 11:19 утра по UTC после того, как обработка существенно восстановилась, и разрешен в 11:57 утра по UTC после того, как время обработки вернулось к норме. ##Продолжение Повторная синхронизация данных для пострадавшего арендатора и мониторинг приема пищи до тех пор, пока данные арендатора не будут подтверждены. Улучшите обработку объекта в индексации бэкэнда, чтобы отставание не накапливалось с такой скоростью.

Автоматический перевод официального обновления инцидента.

1. 14 августа 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 августа 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 августа 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 августа 2026 г. в 10:58 UTCresolved

   Буря запросов на редко используемую функцию модели в IXP Communications Mining вызвала цикл повторных попыток блокировать синхронные запросы в более широком API IXP. Это привело к тому, что запросы провалились с 500-ми, поскольку рабочие были заняты долгосрочными запросами. Автоматическое масштабирование быстро достигло максимальной емкости, и разрешение было сделано только путем применения исправления кода, которое ввело строгие тайм-ауты для внесения запроса API. Шторм запроса начался около 15:10 UTC и обнаружил 15:15 UTC автоматическими сигнализациями. Резолюция была подтверждена около 18:15 UTC. Первоначально инцидент был ошибочно отнесен только к тому, что клиент сделал шторм запросов, но позже было обнаружено, что он повлиял на более широкий круг пользователей. Общее влияние ограничено несколькими пользователями в США.

2. 18 августа 2026 г. в 21:25 UTCpostmortem

   ##Влияние на клиента 12 августа 2026 года, между примерно 15:10 и 18:15 UTC, пользователи Communications Mining (IXP) в регионе Соединенных Штатов испытывали периодические сбои в запросах. Инцидент был ограничен одним из подразделений развертывания в регионе, где пользователи видели сбои в течение пяти-десяти минут, при этом до 5-7% их запросов терпели неудачу с ошибками 5xx на пике. В промежутках между всплесками сервис работал нормально, повторные запросы в целом удались, и никакие данные не были потеряны. ##Коренная причина Буря запросов на редко используемую функцию API, которая вычисляет прогнозы машинного обучения по требованию, совпала с повторной переподготовкой запрашиваемой модели. Каждая переподготовка опровергала кэшированные прогнозы, превращая каждый запрос в многоминутное вычисление. API не устанавливал ограничения по времени на то, как долго запрос может ждать этого вычисления, поэтому эти длительные запросы постепенно занимали всю способность обработки запросов, вызывая несвязанные запросы. Автоматическое масштабирование достигло максимальной мощности быстро и не смогло компенсировать. ## Обнаружение Автоматический мониторинг обнаружил сбои в 15:15 UTC, примерно через пять минут после начала удара, и вызвал инженера по вызову. Первоначально инцидент был связан только с клиентом, генерирующим шторм запросов, но отчеты клиентов и дальнейшее расследование показали, что более широкий набор пользователей пострадал во время всплесков отказов. ## Ответить Инженер на вызове проследил неудачи до неограниченного ожидания в пути прогнозирования по требованию. Пропускная способность сервиса неоднократно восстанавливалась путем автоматической замены экземпляра при разработке исправления кода. Это исправление является строгим тайм-аутом по запросу, поэтому оно быстро не срабатывает, не затрагивая другие запросы, и было развернуто в пострадавшем регионе примерно в 18:00 UTC, а разрешение было подтверждено в 18:15 UTC. ##Поддержка 1.Строгий тайм-аут и фиксация нагрузки были сделаны постоянными и выпущены во все регионы (завершены 13 августа 2026 года). 2. Оценка пределов для каждого клиента на вычислениях прогнозирования по требованию, чтобы использование одного клиента не могло ухудшить общий API.

Автоматический перевод официального обновления инцидента.

1. 10 августа 2026 г. в 14:11 UTCinvestigating

   Мы расследуем ухудшение производительности, влияющее на Front-End Services в понимании документов в регионе GXP East US. Влияние: Пользователи могут заметить тайм-ауты при доступе к пользовательскому интерфейсу в GXP US. Следующее обновление: дополнительные обновления будут предоставляться по мере поступления дополнительной информации.

2. 10 августа 2026 г. в 14:25 UTCresolved

   Проблема была решена, и производительность Front-End Service в Document Understanding вернулась к ожидаемым уровням после того, как ухудшение производительности повлияло на пользовательский интерфейс в регионе GXP East US. Влияние: нет постоянного воздействия пользователя.

3. 19 августа 2026 г. в 06:14 UTCpostmortem

   ##Воздействие на клиента Между 10 августа 2026 года в 13:21 UTC и 10 августа 2026 года в 14:03 UTC, подмножество клиентов испытали ухудшение производительности и тайм-ауты при доступе к пользовательскому интерфейсу Document Understanding, который обеспечивает опыт проектирования в регионе Задержка США. Автоматизация обработки документов не пострадала. ##Коренная причина Во время ручного развертывания из ранее существовавшей сборки сервиса, лежащего в основе пользовательского интерфейса Document Understanding, в Задержанный регион США наш процесс развертывания переназначил идентификатор версии для развертываемой службы. Интерфейс Document Understanding требует, чтобы его вспомогательные ресурсы были доступны под тем же идентификатором версии, что и развернутая служба. Поскольку процесс развертывания изменил этот идентификатор, интерфейс не смог найти необходимые ресурсы, что сделало его недоступным. ## Обнаружение Нам стало известно о проблеме через несколько минут после завершения развертывания посредством ручной проверки в рамках контрольного перечня ручного развертывания. Вскоре последовало автоматическое предупреждение, сработавшее в 13:28 UTC 10 августа 2026 года. ## Ответить После выявления причины сбоя ручного развертывания наша инженерная команда начала развертывать исправленное обновление с необходимыми ресурсами. При этом оперативная группа занималась выполнением ручного отката развертывания. Откат был завершен в 14:03 UTC, восстановив доступ к опыту проектирования. В 14:11 UTC мы опубликовали публичное обновление статуса, указывающее на ухудшение производительности и возможные тайм-ауты в пользовательском интерфейсе Document Understanding для региона США с задержкой. К 14:15 UTC исправленное обновление было завершено, и интерфейс был подтвержден как развернутый с правильной новой версией и работающий. В 14:25 UTC инцидент был помечен как устраненный, и страница с публичным статусом была обновлена, чтобы подтвердить, что производительность интерфейса Document Understanding вернулась к ожидаемым уровням. ##Продолжение 1.Мы сокращаем время, необходимое для восстановления предыдущей версии службы, так что восстановление после неудачного развертывания происходит быстрее. 2. Мы вносим улучшения в процесс ручного развертывания, с тем чтобы предотвратить возникновение ситуации в будущем, подтверждая наличие необходимых ресурсов в качестве предварительного условия.

Автоматический перевод официального обновления инцидента.

1. 8 августа 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 августа 2026 г. в 13:01 UTCidentified

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

3. 8 августа 2026 г. в 14:14 UTCidentified

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

4. 8 августа 2026 г. в 15:30 UTCidentified

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

5. 8 августа 2026 г. в 15:32 UTCmonitoring

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

6. 8 августа 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 августа 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 августа 2026 г. в 21:14 UTCresolved

   Между 06-08-2026 10:00 UTC и 06-08-2026 13:00 UTC некоторые организации в регионе США не смогли завершить прием документов. Небольшое количество поисковых запросов в том же регионе также было медленным или отсроченным. Проблема была вызвана ограничением пропускной способности, влияющим на обработку проглатывания в США. Нормальные показатели были восстановлены в 13:00 UTC. Мы следили за пострадавшей средой с момента восстановления и подтверждаем, что проблема полностью смягчена. Запросы на проглатывание, которые не были выполнены во время этого окна, не были проверены автоматически и должны быть повторно представлены. Для поиска не требуется никаких действий.

2. 13 августа 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.

Автоматический перевод официального обновления инцидента.