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

1. 28 октября 2026 г. в 10:04 UTCinvestigating

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

2. 28 октября 2026 г. в 10:28 UTCmonitoring

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

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

1. 27 октября 2026 г. в 16:39 UTCresolved

   27 октября 2026 года, между 14:35 и 16:08 UTC, в регионе Европы произошло частичное отключение, затрагивающее генеративную экстракцию, генеративную классификацию и автовалидацию. Основной причиной была проблема подключения к стороннему поставщику хранилища. Связь была восстановлена, и мы подтвердили, что добыча и классификация работают нормально с 16:08 UTC.

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

1. 26 октября 2026 г. в 14:04 UTCidentified

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

2. 26 октября 2026 г. в 15:35 UTCidentified

   Проблема с Automation Ops решена. В настоящее время мы ожидаем смягчения проблемы с сервисом Insights. Дальнейшие обновления будут доступны по мере их появления.

3. 26 октября 2026 г. в 17:09 UTCidentified

   Служба Insights в Сингапуре, Японии, Швейцарии, Канаде, Индии, Великобритании, Европе, США, ОАЭ, Южной Корее и Австралии является фиксированной, и мы применяем фиксацию в других регионах

4. 26 октября 2026 г. в 18:27 UTCresolved

   Проблема решена, и сейчас все службы работают в штатном режиме.

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

1. 27 октября 2026 г. в 10:13 UTCresolved

   26 октября 2026 года, между 10:20 и 17:30 UTC, Automation Cloud Robots (VM) испытал частичное отключение, влияющее на работу машины. Во время этого окна такие действия, как запуск, остановка или обеспечение машин виртуальной машины, могут быть не завершены, а запланированные работы на этих машинах могут быть отложены или неисправны. Причиной стала неправильная конфигурация разрешений на подмножестве базовых ресурсов инфраструктуры. Наша команда выявила проблему, исправила конфигурацию и подтвердила, что операции машины работают нормально с 17:30 UTC. Мы пересматриваем, как была введена неправильная конфигурация, и добавляем проверки, чтобы предотвратить повторение. Никаких действий на вашей стороне не требуется. Если вы все еще видите неудачные или застрявшие рабочие места из этого окна, пожалуйста, повторите их и обратитесь в службу поддержки, если проблема сохраняется.

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

1. 23 октября 2026 г. в 21:35 UTCresolved

   Между 20:42 и 21:19 UTC 23 октября некоторые клиенты Orchestrator в Европе увидели медленные ответы и периодические ошибки. Это включало в себя звонки роботов для получения активов, обработки очередей и отчета о статусе работы. Некоторые незанятые рабочие места, возможно, потерпели неудачу за это время. Причиной стало внезапное увеличение нагрузки, которая достигла пределов ресурса базы данных. Мы добавили емкость базы данных, и производительность вернулась к норме с 21:19 UTC. Клиентам, чья работа провалилась в этом окне, возможно, придется перезапустить их.

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

1. 22 октября 2026 г. в 12:59 UTCinvestigating

   Мы выявили проблему, затрагивающую IXP для клиентов, размещенных в регионе Австралии. Начиная с 10:24 UTC, запросы на использование модели Gemini 2.5 Flash в регионе не выполняются. Другие модели не затронуты. Данные клиентов обрабатываются только в Австралии. Мы работаем с Google над восстановлением сервиса

2. 22 октября 2026 г. в 14:19 UTCmonitoring

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

3. 22 октября 2026 г. в 14:33 UTCinvestigating

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

4. 22 октября 2026 г. в 15:42 UTCinvestigating

   Мы связались с Google Support, и они начали расследование. Мы будем следить и делиться обновлениями, как у нас есть.

5. 22 октября 2026 г. в 17:56 UTCmonitoring

   Мы наблюдаем улучшение трафика Gemini 2.5 Flash. Мы отслеживаем возможное исправление от Google.

6. 22 октября 2026 г. в 21:02 UTCresolved

   Проблема решается Google.

7. 26 октября 2026 г. в 03:20 UTCpostmortem

   ##Воздействие на клиента Между 22 октября 2026 года в 10:24 утра UTC и 22 октября 2026 года в 6:04 вечера UTC, запросы на обработку документов, которые использовали Gemini 2.5 Flash в австралийском регионе, потерпели неудачу с ошибками пропускной способности. Удар длился примерно 7 часов 40 минут. Была затронута подгруппа клиентов, использующих рабочие процессы по извлечению документов в этом регионе. Во время временной попытки резервного копирования в регионе некоторые запросы на извлечение ненадолго восстановились, но атрибуция на уровне слов и сгенерированный текст страницы были ухудшены, пока резервный копия также не начала давать сбой. ##Коренная причина Основной причиной стало нарушение работы региональной сети на стороне провайдера при одновременном обслуживании. Это вызвало серьезное дросселирование полосы пропускания в среде обслуживания моделей провайдера, что помешало бэкэнд-системам загружать данные модели, необходимые для надежного обслуживания запросов Gemini 2.5 Flash и Gemini 3.5 Flash в пострадавшем регионе. ## Обнаружение Проблема была обнаружена с помощью автоматического оповещения, которое идентифицировало ошибки ограничения скорости на Gemini 2.5 Flash в регионе Австралии. Наша инженерная команда подтвердила с помощью телеметрии, что затронутые запросы последовательно терпят неудачу, и начала координировать ответ. ## Ответить В 1:40 вечера UTC мы направили затронутый трафик Gemini 2.5 Flash в Gemini 3.5 Flash в том же регионе для сохранения резидентности данных. Первоначальная телеметрия не показала ошибок емкости после этого изменения, но к 2:10 вечера UTC, Gemini 3.5 Flash также возвращал ошибки емкости, поэтому запасной вариант больше не был жизнеспособным. В 2:05 вечера по UTC мы скорректировали соответствующие пути обработки документов, поэтому генерация атрибуции и текста страницы будет использовать тот же запасной вариант в регионе; эта корректировка завершена примерно в 2:09 вечера по UTC. После того, как запасной вариант также не удался, мы изменили маршрутизацию, и к 4:28 вечера трафик UTC вернулся на ожидаемый путь Gemini 2.5 Flash. В 5:38 вечера UTC телеметрия показала улучшение показателей успеха Gemini 2.5 Flash. С 6:04 вечера UTC не наблюдалось никаких дальнейших ошибок емкости, и последующие запросы увенчались успехом. ##Продолжение 1. Завершить зарезервированную модель оценки пропускной способности пострадавшего региона с использованием наблюдаемых моделей движения 2.Оценить поведение повторных и обратных операций в клиентах обработки документов, чтобы уменьшить усиление повторных операций при сбоях пропускной способности на стороне поставщика.

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

1. 15 октября 2026 г. в 12:27 UTCinvestigating

   Начиная примерно с 11:17 UTC, клиенты во многих регионах столкнулись с проблемами с UiPath Agents и Solutions Management. Новые рабочие места могут оставаться в состоянии ожидания, а работающие агенты могут испытывать задержки при обработке эскалации или ожидании результатов инструмента. Мы расследуем этот вопрос и работаем над его решением.

2. 15 октября 2026 г. в 13:04 UTCmonitoring

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

3. 15 октября 2026 г. в 13:22 UTCresolved

   Этот инцидент был урегулирован. В период с 11:15 по 12:45 по 15 октября проблема внутренней конфигурации не позволила провести некоторые мероприятия между службами UiPath в нескольких регионах. Проблема была решена путем отмены изменений, и новая деятельность обрабатывается нормально. Некоторые работы, начатые или продолжающиеся во время этого окна, могут потребовать внимания: Агенты: Агенты, ожидающие выполнения задач Центра действий или результатов инструментов автоматизации, могут оставаться в тупике. Работа, начатая с оркестратора, также может показаться застрявшей или временной. Maestro: Процессы, ожидающие выполнения пользовательских задач, возможно, не возобновились после завершения задачи. - Приложения: статусы очередей могут быть устаревшими, а действия, вызванные завершением очередей, могут не выполняться. Автопилот для всех: разговоры, ожидающие результатов автоматизации, могут застопориться. Понимание документов и контекстное обоснование: Автоматизация и агенты, ожидающие извлечения, проверки или индексации, могут оставаться приостановленными. Интеграция: события подключения могут не вызвать ожидаемых процессов или уведомлений. Решения и веб-студия: Установка, удаление, публикация, развертывание и валидация, начатые в течение этого окна, могут быть неудавшимися или отсроченными. Перепроверка этих операций может решить проблему. Мы приносим извинения за нарушение и благодарим вас за терпение.

4. 21 октября 2026 г. в 06:47 UTCpostmortem

   ** Влияние клиента** 15 октября 2026 года с 11:15 до 12:50 UTC (около 1 часа 35 минут) некоторые мероприятия, которыми обменивались облачные сервисы UiPath, не были доставлены. Пострадали клиенты во всех коммерческих облачных регионах. Во время этого окна: - Новые агенты могут остаться в статусе "В ожидании". Запуск агентов, ожидающих результата инструмента, человеческая эскалация, извлечение документов или обоснование контекста могут не возобновиться. Разговорные агенты и автопилот для всех разговоры, которые начали автоматизацию, возможно, не получили своего результата. Процессные экземпляры Maestro, ожидающие задачи пользователя, возможно, не продвинулись вперед после завершения задачи, а процессы, вызванные событиями разъема службы интеграции, возможно, не начались. Приложения, показывающие или реагирующие на статус пункта очереди, могут показывать устаревшую информацию. Установки, удаление, публикации и развертывание могут выйти из строя или выйти из строя. Некоторые изменения пользователей, групп и папок, внесенные в окно, могут не распространяться на все службы. Работы, начатые после 12:50 UTC, не пострадали. Работа робота, очереди и триггеры, обработанные внутри оркестратора, работали нормально. ** Коренная причина** Мы переводили внутреннюю конфигурацию обслуживания на новый механизм, изменение, которое не должно было повлиять на клиентов. Когда это изменение было применено к службе доставки событий, конфигурация, которую она произвела, отсутствовала требуемое значение. Без него сервис рассматривал несколько интеграций продуктов как выключенные и молча перестал доставлять свои мероприятия. Поскольку изменения коснулись всех производственных регионов одновременно, пострадали все регионы. ** Обнаружение** Проблема была обнаружена в 11:51 UTC, примерно через 35 минут после начала воздействия, когда мониторинг был предупрежден о работе агента, остающегося в статусе. Последовали сообщения о сроках развертывания решений, и инцидент был объявлен в 12:12 UTC. ** Ответ** После первого обнаружения в 11:51 UTC было выявлено изменение конфигурации и в 12:00 UTC был начат откат. Первоначальный откат в 12:14 UTC не полностью восстановил доставку. Затем команда остановила процесс доставки новой конфигурации и восстановила предыдущую. Доставка событий начала восстанавливаться в 12:40 UTC, а полное восстановление во всех регионах было подтверждено в 12:50 UTC. Там, где это возможно, мы воспроизводили пропущенные события, чтобы затронутая работа могла продолжаться. ** Следуйте ** 1. Новый процесс доставки конфигурации был приостановлен для затронутой службы и будет оставаться приостановленным до тех пор, пока конфигурация не будет сформирована правильно. 2. Валидировать конфигурацию, создаваемую новым механизмом доставки для требуемых значений, прежде чем она будет применена к любой среде. 3. Постепенно вносить изменения в конфигурационную доставку по регионам, а не во все регионы одновременно. 4. Улучшить наш мониторинг, чтобы обнаружить в течение нескольких минут, когда события перестают доставляться к интеграции продукта, который обычно получает их. 5. Улучшить нашу способность восстанавливаться и восстанавливать события, пропущенные во время сбоя.

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

1. 15 октября 2026 г. в 12:03 UTCresolved

   Некоторые клиенты в регионе США испытывали задержки в приеме роботизированных журналов, причем повышенная активность наблюдалась примерно между 11:20 и 11:45 UTC. Проблема была решена, и проглатывание журнала вернулось к норме. Спасибо за ваше терпение.

2. 22 октября 2026 г. в 10:13 UTCpostmortem

   ##Воздействие на клиента В период примерно с 15 октября 2026 года в 11:20 вечера по UTC и примерно с 15 октября 2026 года в 11:45 вечера по UTC некоторые клиенты в Восточном регионе США испытывали задержки в проглатывании журналов роботов в UiPath Orchestrator. Журналы роботов не были обновлены в течение затронутого периода. Удар длился примерно 20 минут. ##Коренная причина Во время инцидента было отмечено, что 2 из 13 случаев обслуживания, связанных с проглатыванием журнала робота, не были подключены к службе приема. Отказались только запросы в службу приема пищи, и только в этих двух случаях. Это привело к тому, что некоторые запросы на вход в журнал робота не были успешно выполнены, что привело к задержке данных журнала для пострадавших клиентов. Коренная причина, по которой только эти два случая потеряли связь со службой приема, не была определена во время инцидента. Команда взяла на себя обязательство провести после инцидента обзор журналов из пострадавших случаев, чтобы определить основную причину. Мы считаем, что это несообщаемая проблема инфраструктуры от нашего облачного провайдера. ## Обнаружение Проблема была обнаружена с помощью автоматического оповещения примерно в 11:33 вечера по Гринвичу 15 октября 2026 года и подтверждена с помощью телеметрии, показывающей исключения из двух пострадавших случаев обслуживания. ## Ответить После обнаружения телеметрия подтвердила, что только в двух случаях службы были сделаны исключения. Респонденты удалили эти два нездоровых случая из службы, и замена началась автоматически. В течение примерно 20 минут после первого оповещения — примерно к 11:53 вечера по Гринвичу — телеметрия показала, что восстановление и синтетические контрольные проверки проходят. Был рассмотрен, но не выполнен более широкий перезапуск всех случаев обслуживания, поскольку команда определила, что он не должен продолжаться без предварительного понимания первопричины. ##Продолжение 1.После инцидента обзор журналов из затронутых случаев обслуживания показал, что проблема была связана с инфраструктурой, и мы следим за поставщиком облачной инфраструктуры для получения более подробной информации. 2. Обновление будет опубликовано, если расследование даст дополнительные результаты.

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

1. 14 октября 2026 г. в 07:26 UTCmonitoring

   Начиная с 6:50 UTC, мы столкнулись с глобальным отключением, которое повлияло на загрузку приложений и закодированных приложений во всех регионах, за исключением Индии и Великобритании. Отключение было устранено, и службы работают в полном объеме. Влияние: нет постоянного воздействия пользователя.

2. 14 октября 2026 г. в 07:43 UTCresolved

   Начиная с 6:50 UTC, мы столкнулись с глобальным отключением, которое повлияло на загрузку приложений и закодированных приложений во всех регионах, за исключением Индии и Великобритании. Отключение было устранено, и службы работают в полном объеме. Влияние: нет постоянного воздействия пользователя.

3. 23 октября 2026 г. в 12:08 UTCpostmortem

   ##Воздействие на клиента Между 06:38 UTC и 07:21 UTC 14 октября 2026 года часть запросов к UiPath Apps, Coded Apps и решениям, которые зависят от них, потерпели неудачу в одиннадцати регионах: Европе, США, Сообществе, Японии, Сингапуре, Австралии, Канаде, Южной Корее, Швейцарии, ОАЭ и отложенной среде США. Регионы Индии и Соединенного Королевства не пострадали. Около 2 процентов запросов в целом не удалось, от 0,6 до 5 процентов в зависимости от региона. Пострадавшие пользователи видели, что приложения не загружаются, запросы возвращают ошибки сервера или медленные ответы. В регионах, где должны были быть перезапущены служебные контейнеры, приложения были недоступны в течение примерно восьми минут. Время отклика вернулось к норме в каждом регионе к 07:40 UTC. Большинство пользователей уже запущенных приложений заметили мало или ничего. Определения приложений кэшируются в браузере в течение 24 часов, данные приложения поступают из Службы данных и Оркестратора, а не из этой базы данных, и служба поддерживает соединения с базой данных, которые она уже провела. Неудачными оказались запросы, требующие нового подключения к базе данных: открытие конструктора или списка приложений, загрузка еще не кэшированного приложения, загрузка документов и изображений, хранящихся в приложениях, а также сохранение или публикация. ##Коренная причина В 06:38 UTC, в то время как доступ к базе данных был настроен для нового регионального развертывания, пароль пользователя базы данных, который использует сервис Apps, был изменен. Этого пользователя разделяют кластеры производственных баз данных всех затронутых регионов, поэтому изменение применяется ко всем из них сразу. Запущенные сервисы по-прежнему сохраняли предыдущий пароль и больше не могли открывать новые подключения к базе данных. Регионы Индии и Соединенного Королевства не используют эти полномочия и не пострадали. Изменения были направлены на создание отдельного пользователя базы данных для нового региона. Вместо этого был изменен пароль существующего пользователя, которым делятся все регионы. Наш процесс изменения учетных данных баз данных явно не отделял создание новых учетных данных от изменения существующих, и он не требовал проверки того, сколько кластеров и регионов повлияет на изменение учетных данных. В сочетании с единым пользователем базы данных, распространяемым по регионам, это позволило изменить ситуацию, предназначенную для одного региона, чтобы вызвать отключение нескольких регионов. ## Обнаружение Наш внутренний мониторинг поднял первое предупреждение в 06:41 UTC, через три минуты после первых сбоев, и оповещения для каждого пострадавшего региона, за которым последовало 06:46 UTC. В 06:50 UTC инженер подтвердил, что каждый производственный кластер был отклонен его базой данных и начал процесс инцидента. ## Ответить В 07:05 UTC был восстановлен предыдущий пароль и повсеместно прекратились сбои аутентификации. Большинство регионов подключаются автоматически. В регионах, которые не сделали этого, служебные контейнеры были перезапущены или передислоцированы: США задержали в 07:21 UTC и Швейцария к 07:30 UTC. Сбои в запросах прекратились в 07:21 UTC, время ответа было возвращено к исходному уровню к 07:40 UTC, и мы продолжали мониторинг, пока инцидент не был разрешен в 07:43 UTC. ##Продолжение Чтобы это не повторилось, мы: Внедрение определенной процедуры создания и вращения учетных данных базы данных с предварительным обзором изменений, в котором говорится, какие кластеры и регионы разделяют учетные данные, и поэтапное развертывание, которое проверяется в одном регионе, прежде чем оно будет применяться более широко. - переход к отдельным пользователям баз данных с наименьшими привилегиями для каждого региона, чтобы изменения в одном регионе не могли повлиять на другой. Автоматически объявляя о происшествии и подкачивая владельцев баз данных, когда одна и та же ошибка обнаруживается в нескольких регионах одновременно, вместо того, чтобы полагаться на ручную эскалацию из отдельных региональных оповещений. - Предоставление сервисам возможности получать обновленные учетные данные базы данных без перезагрузки и быстрее подключаться после сбоя аутентификации.

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

1. 13 октября 2026 г. в 14:03 UTCinvestigating

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

2. 13 октября 2026 г. в 14:37 UTCinvestigating

   Мы продолжаем расследование этого вопроса.

3. 13 октября 2026 г. в 14:42 UTCinvestigating

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

4. 13 октября 2026 г. в 15:10 UTCinvestigating

   Реализовано исправление, и мы отслеживаем результаты.

5. 13 октября 2026 г. в 15:19 UTCresolved

   Этот инцидент был устранен после обновления истекшего SSL-сертификата, который затронул несколько ML-зависимых сервисов, включая IXP, Document Understanding, Computer Vision, Semantic Proxy и Autopilot для разработчиков. Восстановление обслуживания произошло в пострадавших регионах, и были настроены автоматические оповещения, чтобы помочь обнаружить истечение срока действия сертификата и предотвратить подобные сбои в будущем. Спасибо за ваше терпение и понимание.

6. 26 октября 2026 г. в 03:17 UTCpostmortem

   ##Влияние на клиента В период с 13:37 по 14:40 UTC 13 октября 2026 года клиенты во многих регионах не смогли использовать IXP Unstructured Documents, IXP Communications Mining и Document Understanding. Функции Computer Vision и Autopilot для разработчиков, зависящие от одних и тех же сервисов машинного обучения, также не удались. Пострадавшие клиенты видели, что запросы терпят неудачу с ответами «500 внутренних ошибок сервера» или тайм-аутом, проектами IXP, которые не будут открываться, и действиями Computer Vision, не выполняющими автоматизацию. Служба была прервана примерно на 1 час. Данные клиентов не были потеряны. ##Коренная причина Инцидент был вызван просроченным сертификатом безопасности, используемым для установления безопасных соединений с этими службами. Сертификат обновляется автоматическим процессом. Этот процесс больше не был успешным, и сбои не вызвали тревогу, поэтому сертификат не был заменен до истечения срока его действия. Защищенные соединения с затронутыми службами были отклонены в 13:37 UTC. ## Обнаружение Автоматизированный мониторинг начал оповещение об ошибках и пропаже трафика в 13:40 UTC, а инцидент был объявлен в 13:54 UTC. Срок действия сертификата был определен в 14:00 UTC, а первое обновление страницы статуса было опубликовано в 14:03 UTC. Никакое предупреждение не предупреждало о том, что срок действия сертификата приближается к концу, и о неоднократных сбоях автоматического обновления не сообщалось в владеющую команду, поэтому проблема была обнаружена только после того, как клиенты были затронуты. ## Ответить В 14:06 UTC команда подтвердила, что срок действия сертификата истек, поскольку автоматическое обновление не удалось. В 14:18 UTC было выдано новое удостоверение для процесса обновления. Обновление было начато вручную в 14:19 UTC и завершено в 14:33 UTC, а к 14:37 UTC каждая конечная точка, обращенная к клиенту, была проверена для обслуживания обновленного сертификата. Трафик вернулся к нормальному уровню примерно к 14:40 UTC. После периода мониторинга инцидент был урегулирован в 15:19 UTC. ##Поддержка Чтобы предотвратить подобные инциденты в будущем, мы вносим следующие улучшения: - Сообщите заранее о том, что любой из этих сертификатов подходит к концу. - Уведомлять собственную команду всякий раз, когда автоматическое обновление не удается. Добавьте проверки, которые предупреждают, как только безопасные соединения с этими службами выходят из строя. Укрепить право собственности на процесс обновления сертификата и учетные данные, на которые он опирается.

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

1. 13 октября 2026 г. в 10:32 UTCinvestigating

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

2. 13 октября 2026 г. в 10:57 UTCresolved

   Этот вопрос решен. Журналы выполнения роботов синхронизируются и снова видны в Orchestrator для Japan Orchestrator. Спасибо за ваше терпение.

3. 22 октября 2026 г. в 13:25 UTCpostmortem

   ##Воздействие на клиента Между примерно 07:00 UTC 9 октября 2026 года и 10:45 UTC 13 октября 2026 года около 6% записей журнала роботов для клиентов в регионе Японии не появлялись в Orchestrator. Исполнение работы и все другие функции оркестратора не были затронуты. Пропавшие записи стали видны в Orchestrator после того, как проблема была исправлена. ##Коренная причина Журналы роботов размещаются в очереди, разделенной на 32 раздела, а служба приема внутрь считывает каждый раздел и хранит журналы для Orchestrator. 9 октября служба приема пищи в регионе Японии прекратила чтение с 2 из 32 разделов, не сообщив об ошибке. Логи на этих перегородках хранились в очереди, но не хранились, поэтому в оркестроре они не появлялись. Наш мониторинг проверял сервис в целом, не каждый раздел, поэтому проблема не была обнаружена автоматически. ## Обнаружение Проблема была обнаружена в отчетах клиентов. Мы объявили об инциденте в 10:13 UTC 13 октября и разместили уведомление на странице статуса в 10:32 UTC. ## Ответить Мы возобновили прием пищи примерно в 10:41 UTC, и он возобновил чтение всех разделов. Держащиеся в очереди бревна затем обрабатывались и становились видимыми в оркестроре. Инцидент был урегулирован в 10:57 UTC. ##Продолжение Мы добавляем мониторинг, который предупреждает нас, когда какой-либо отдельный раздел перестает читаться, поэтому такая проблема обнаруживается в течение нескольких минут.

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

1. 7 октября 2026 г. в 21:34 UTCinvestigating

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

2. 8 октября 2026 г. в 01:30 UTCidentified

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

3. 8 октября 2026 г. в 03:28 UTCmonitoring

   Мы внедряем исправление для отключения, влияющего на создание задач HITL для Maestros, с таймерами HITL, настроенными в США, и работаем над смягчением проблемы. Влияние: пользователи могут быть не в состоянии создавать задачи HITL в Maestros с настроенными таймерами HITL-задач SLA. Следующее обновление: наши команды работают над смягчением проблемы и будут делиться обновлениями по мере их доступности.

4. 8 октября 2026 г. в 04:29 UTCresolved

   Решение проблемы создания задач HITL для Maestro с помощью таймеров HITL SLA, настроенных в США, было полностью развернуто. Создание задач HITL вернулось в нормальное русло.

5. 26 октября 2026 г. в 03:16 UTCpostmortem

   ##Воздействие на клиента На 2026-10-05 между 9.30 вечера UTC - 2026-10-07 3.30 утра Клиенты UTC, Maestro BPMN и Case, использующие узлы HITL с настроенным таймером задач, видели сбои своих отладки и производственных экземпляров на этапе HITL с 4xx. Было выявлено около 30 таких случаев среди клиентов в США и Европе, которые были заблокированы без каких-либо обходных путей. ##Коренная причина Настройка задачи SLA требует объекта, включая критерии начала и конца, таймер SLA и результат нарушения SLA. Клиенты настраивают это на конструкторе Maestro на узле HITL. Результат был ошибочно оставлен необязательным на поверхности дизайна, хотя конфигурация SLA без результата не сохраняется и не имеет смысла для бизнеса. Бэкэнд-команда Центра действий добавила проверку, чтобы бросить плохой запрос (400) в случае ненулевого объекта SLA с недостающим результатом. Это в конечном итоге повлияло на клиентов, которые добавили критерии «Пуск / конец» на узле, но не настроили результат. Случаи, которые ранее были запущены, потерпели неудачу с 400-ми и не смогли возобновиться. ## Обнаружение Клиент сообщил об этом Maestro Engineering SME, который поднял этот вопрос вместе с командой. Команда Маэстро исследовала этот сбой и наблюдала все большее число сбоев для USI и нескольких других арендаторов через журналы, что привело их к привлечению команды Центра действий. ## Ответить Команда Maestro получила сообщение о проблеме от клиента по электронной почте, и они провели некоторое первоначальное расследование и определили потенциальную регрессию, после которой был задействован Центр действий МСП, проблема воспроизводилась в более низких средах, откат функции, примененной и протестированной, и развернута во всех пострадавших регионах. Он был урегулирован, и все случаи были проверены и возобновлены. ##Продолжение 1. Добавить валидацию для этого сценария на всех поверхностях кросс-сервисной кодовой базы для обеспечения обзора человеком 2. Добавить необходимые контрольные и интеграционные тесты для более быстрого выявления этой проблемы

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

1. 7 октября 2026 г. в 17:37 UTCinvestigating

   Мы расследуем сообщения о прерывистой медлительности и ошибках, затрагивающих подгруппу организаций в Восточноамериканском регионе Облака автоматизации. Пострадавшие пользователи могут видеть, что страницы в пользовательском интерфейсе Orchestrator не загружаются (например, страница Джобса возвращает «Произошла ошибка»), а операции робота, такие как транзакции очереди и запуск сеанса, могут периодически выходить из строя. Мы предоставим обновление, как только будет доступна дополнительная информация.

2. 7 октября 2026 г. в 18:13 UTCmonitoring

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

3. 7 октября 2026 г. в 19:06 UTCresolved

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

4. 14 октября 2026 г. в 11:42 UTCpostmortem

   ##Воздействие на клиента Между 13:00 UTC и 18:15 UTC 7 октября 2026 года клиенты в регионе США испытывали периодические ошибки и медленные ответы в Orchestrator. Пострадавшие пользователи, возможно, видели, что страницы Orchestrator не загружаются, например, страница Джобса, возвращающая «Произошла ошибка», и операции робота, такие как транзакции очереди и запуск сеанса, могут периодически отсчитываться. Другие сервисы UiPath, зависящие от Orchestrator, также могли видеть более медленные ответы или ошибки в течение этого периода. ##Коренная причина Несколько часто используемых операций Orchestrator опирались на общий недолговечный ресурс в базе данных, включая рутинную проверку состояния, которую выполняет каждый работающий робот. По мере роста объемов параллельной деятельности роботов в этом регионе, вместо завершения их работы, стали возникать очереди за доступом к этому общему ресурсу. Эффект был избирательным, а не общим замедлением: операции, которые использовали этот ресурс, задерживались, в то время как другие продолжали работать нормально. Поскольку процессор базы данных, память и использование хранилища оставались в пределах нормы, обычный мониторинг емкости не указывал на проблему. ## Обнаружение Наш автоматизированный мониторинг выявил ухудшение в течение примерно 35 минут после начала воздействия на клиента, и наши инженеры определили основное противоречие во время мероприятия. Поскольку это была проблема спора, а не дефицита потенциала, и все показатели потенциала были нормальными, увеличение емкости базы данных, как ожидается, не решит ее, и группа исследовала альтернативы, прежде чем применять ее. Эта оценка задержала смягчение последствий. ## Ответить Наша инженерная команда увеличила емкость базы данных. Время отклика и частота ошибок немедленно вернулись к норме, и мы продолжили мониторинг, чтобы подтвердить, что служба была стабильной до закрытия инцидента. 13:00: Ставки ошибок и время отклика начинают расти для клиентов в регионе США. 13:36 Автоматизированный мониторинг обнаруживает деградацию и уведомляет команду инженеров по вызову. 13:36-17:29 Инженеры исследуют. Все стандартные индикаторы емкости базы данных — процессор, память и хранилище — остаются в пределах нормы, поэтому причина не очевидна из рутинного мониторинга. 17:29: Объявляется официальный инцидент и задействована команда полного реагирования. 17:38 Публичное уведомление опубликовано на [UiPath Status] (http://status.uipath.com/). (расследование). 17:31 – 17:43 Для пострадавшего региона предусмотрена дополнительная база данных. * 18:00: Коэффициенты ошибок, время отклика и задержка запроса возвращаются к нормальному уровню. 18:11: Страница статуса обновляется до окончания мониторинга и воздействия на клиента. 19:06: Инцидент закрыт после того, как непрерывный мониторинг подтверждает, что служба стабильна. ##Продолжение Чтобы это не повторилось, мы: • Изменять операции, чтобы они больше не зависели от общего ресурса. Это было распространено на все затронутые системы и существенно снизило состояние, которое вызвало инцидент. Включение подробного мониторинга баз данных в этих системах, так что этот класс споров виден, пока это происходит, а не после. Улучшение нашего оповещения таким образом, чтобы подлинная деградация такого рода четко отличалась от рутинной, самокорректирующейся вариации и усиливалась быстрее.

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

1. 6 октября 2026 г. в 17:50 UTCinvestigating

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

2. 6 октября 2026 г. в 18:28 UTCidentified

   Мы определили причину отключения, влияющего на проглатывание журналов роботов для Orchestrator в Европе. Влияние: Пользователи могут ожидать задержки с проглатыванием журналов роботов и / или поиском / отображением журналов. Никакие бревна не будут потеряны. Наши команды работают над тем, чтобы понять причину и масштаб, и будут делиться обновлениями по мере их доступности.

3. 6 октября 2026 г. в 18:43 UTCmonitoring

   Мы смягчили проблему, влияющую на проглатывание журналов роботов для Orchestrator в Европе. Влияние: Пользователи могут ожидать задержки с проглатыванием журналов роботов и / или поиском / отображением журналов. Никакие бревна не будут потеряны. Наши команды работают над тем, чтобы понять причину и масштаб, и будут делиться обновлениями по мере их доступности.

4. 6 октября 2026 г. в 18:44 UTCresolved

   Мы смягчили проблему, влияющую на проглатывание журналов роботов для Orchestrator в Европе. Влияние: Пользователи могут ожидать задержки с проглатыванием журналов роботов и / или поиском / отображением журналов. Никакие бревна не будут потеряны. Наши команды работают над тем, чтобы понять причину и масштаб, и будут делиться обновлениями по мере их доступности.

5. 7 октября 2026 г. в 11:08 UTCpostmortem

   ##Воздействие на клиента В период между 15:45 UTC и 18:45 UTC клиенты, размещенные в Европе, Австралии и Японии, не смогли увидеть последние записи роботов в Orchestrator. Журналы, написанные во время окна удара, не появлялись в просмотрах Jobs and Logs или через API Robot Logs, а журналы старше примерно 03:00 UTC в тот день были доступны только периодически. Окно удара различалось по регионам: Австралия: приблизительно 15:45 UTC до 18:35 UTC - Европа: приблизительно 16:35 UTC до 18:00 UTC Япония: приблизительно 16:45 UTC до 18:30 UTC Выполнение работы, очереди, триггеры и все другие функции оркестратора не были затронуты. Ни один робот не был потерян. Логи, изготовленные во время окна удара, продолжали собираться и снова становились видимыми после того, как проблема была смягчена. ##Коренная причина Мы проводили плановое обновление сервиса Elasticsearch, в котором хранятся журналы роботов Orchestrator. Модернизация использует сине-зеленый подход: новый кластер создается вместе с существующим, данные восстанавливаются в него из резервной копии, на нем запускается трубопровод, который проглатывает новые журналы, и только после этого переключается трафик. В пострадавших регионах коммутатор трафика был одобрен инженером, выполняющим обновление до восстановления данных и завершения догоняющего приема, что является отклонением от нашей процедуры обновления. Это была человеческая ошибка. В результате Orchestrator считывал журналы роботов из кластера, которые еще не содержали последних данных, в то время как новые журналы продолжали собираться, но еще не были проиндексированы на кластере, обслуживающем запросы. Ошибка не была обнаружена, потому что наш инструментарий развертывания полагается на оператора для проверки полноты данных и не обеспечивает порядок между восстановлением данных и коммутатором трафика. ## Обнаружение Наш синтетический мониторинг, который постоянно выполняет тестовые задания и проверяет, что их журналы возвращаются, обнаруживает недостающие журналы в пострадавших регионах и поднимает тревоги. Наша инженерная команда соотнесла предупреждения с текущим обновлением, объявила об инциденте и опубликовала уведомление о статусе. ## Ответить Наша команда инженеров вернула трафик к предыдущим кластерам Elasticsearch во всех трех регионах, что немедленно восстановило доступ ко всем журналам роботов, в том числе к тем, которые были созданы во время окна удара. Мы подтвердили восстановление с помощью синтетического мониторинга в каждом пострадавшем регионе и продолжили мониторинг, прежде чем отметить инцидент, разрешенный примерно в 18:45 по Гринвичу. Обновление новых кластеров продолжается в фоновом режиме. Трафик будет перемещен на них только после того, как восстановление данных будет завершено и прием будет подтвержден. ##Продолжение Чтобы это не повторилось, мы: Изменение конвейера развертывания так, чтобы переключатель трафика не мог работать до тех пор, пока восстановление данных и загрузка журнала в новом кластере не будут проверены как завершенные. Добавление автоматического шага отката к трубопроводу, чтобы трафик мог быть возвращен в предыдущий кластер в течение нескольких минут, если проблема обнаружена после переключателя.

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

1. 6 октября 2026 г. в 12:38 UTCidentified

   Мы наблюдаем снижение производительности услуг в ОАЭ

2. 6 октября 2026 г. в 12:43 UTCinvestigating

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

3. 6 октября 2026 г. в 14:01 UTCidentified

   Мы определили проблему как проблему маршрутизации сети со сторонним поставщиком услуг, что влияет на подключение к нашим услугам, размещенным в ОАЭ. Мы работаем с нашим провайдером по разрешению и будем обновлять прогресс здесь.

4. 6 октября 2026 г. в 14:22 UTCidentified

   Мы продолжаем работать над решением этой проблемы.

5. 6 октября 2026 г. в 14:51 UTCmonitoring

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

6. 6 октября 2026 г. в 15:09 UTCmonitoring

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

7. 6 октября 2026 г. в 17:09 UTCresolved

   Инцидент был урегулирован.

8. 21 октября 2026 г. в 05:36 UTCpostmortem

   ##Воздействие на клиента Между 12:38 PM UTC и 2:51 PM UTC подгруппа клиентов в регионе ОАЭ испытывала сбои при доступе к облачным сервисам UiPath. Инцидент длился примерно 2 часа 13 минут. Пострадавшие услуги включали доступ к **cloud.uipath.com**, **account.uipath.com** Услуги, размещенные в ОАЭ. Клиенты могли столкнуться с тайм-аутами, неудавшейся аутентификацией, сбросом соединений или ошибками сервера. ##Коренная причина Основной причиной был сбой маршрутизации региональной сети у стороннего поставщика инфраструктуры. Подмножество исходящих сетевых путей из региона UAN в конкретные внешние сети, включая сеть доставки контента, обслуживающую **cloud.uipath.com** и **account.uipath.com**, прекратили доставку трафика. Новые попытки исходящего соединения от затронутых служб не получили ответов, в результате чего запросы были отложены. Наша инженерная команда исключила в качестве причин конфигурацию сервиса UiPath, политику уровня приложений и пропускную способность исходящего соединения. Поставщик инфраструктуры признал известную проблему, затрагивающую нескольких клиентов на одном сетевом пути. ## Обнаружение Проблема была обнаружена с помощью автоматизированного мониторинга. Примерно к 12:40 вечера UTC — примерно через две минуты после начала сбоя — расследование подтвердило, что новые соединения из пострадавших служб региона УАН с ключевыми конечными точками UiPath терпят неудачу. ## Ответить К 1:20 вечера UTC наша команда инженеров подтвердила, что сбой был ограничен конкретными исходящими сетевыми путями, в то время как другие пункты назначения оставались доступными. Валидация исключила изменения маршрутизации на стороне UiPath, изменения конфигурации доставки контента, политику уровня приложений и проблемы пропускной способности исходящего соединения. В отношении стороннего поставщика инфраструктуры было возбуждено дело о поддержке с высокой степенью тяжести. В 1:50 вечера UTC провайдер признал известную проблему, затрагивающую нескольких клиентов. Наша команда продолжала следить за восстановлением пострадавших сетевых путей и проверять работоспособность сервиса по мере возвращения трафика. В 2:51 вечера UTC проверки восстановления подтвердили, что трафик UiPath через затронутые пути доставки контента вернулся к нормальному уровню. Автоматизированные проверки здоровья и показатели обслуживания подтвердили восстановление, и Службы в УАН были введены в эксплуатацию. ##Продолжение 1. Мы проводим подтвержденные корректирующие действия поставщика инфраструктуры и анализ первопричин сбоя региональной маршрутизации. 2. Мы рассматриваем зависимость от исходящих услуг в пострадавшем регионе для повышения устойчивости к аналогичным сбоям в работе сетей третьих сторон.

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

1. 2 октября 2026 г. в 16:23 UTCinvestigating

   Начиная примерно с 15:05 UTC, некоторые клиенты в регионе США могут видеть, что для запуска или пребывания в штате Пенсильвания работа, выполняемая на облачных роботах, занимает больше времени, чем обычно. Рабочие места на собственных роботах не затронуты, как и другие регионы. Мы нашли вероятную причину и работаем над восстановлением нормальной работы. Рабочие места, которые уже стоят в очереди, не теряются и будут обработаны после решения проблемы. Мы опубликуем еще одно обновление в течение 60 минут.

2. 2 октября 2026 г. в 16:34 UTCmonitoring

   Мы применили исправление проблемы, которая задержала рабочие места на Cloud Robots в регионе США, и рабочие места снова начинаются нормально. Работы, которые были отложены, сейчас обрабатываются. Мы отслеживаем, чтобы убедиться, что сервис остается стабильным и опубликует еще одно обновление в течение 60 минут.

3. 2 октября 2026 г. в 16:51 UTCmonitoring

   После дальнейшей работы над этим вопросом рабочие места в области облачных роботов в США начинаются нормально. Рабочие места, которые были отложены ранее, обрабатываются. Мы продолжаем следить за сервисом и опубликуем еще одно обновление, как только проблема будет решена.

4. 2 октября 2026 г. в 17:03 UTCresolved

   Этот вопрос решен. Между 15:05 и 16:39 по Гринвичу рабочие места на Cloud Robots в регионе США были медленными, чтобы начать или остаться в штате. Рабочие места начинаются нормально с 16:39 UTC, и рабочие места, которые были отложены в течение этого времени, теперь обработаны. Мы приносим извинения за срыв.

5. 14 октября 2026 г. в 14:20 UTCpostmortem

   ##Воздействие на клиента С 15:00 до 16:38 UTC на 2026-10-02, работа Cloud Robots в регионе США заняла больше времени, чем обычно, до 22 минут на пике около 16:20 UTC. Оркестратор остался в наличии, ни одна работа не была потеряна, ни один другой регион не пострадал. Небольшое количество клиентов получили временную ограничительную ошибку при подаче новых заявок, в то время как их более ранние работы ждали. ## Обнаружение Автоматические оповещения выпущены в 15:07 UTC, через семь минут после начала удара. Проверки в регионе США провалились примерно с 15:32 UTC, и началось реагирование на инцидент. ##Коренная причина В 14:55 UTC один клиент начал предоставлять рабочие места примерно в 20 раз чаще, чем обычно. Служба, которая признает рабочие места, ведет учет параллелизма в базе данных и обновляет его под блокировкой базы данных на каждом начале и конце работы. При таком темпе очередь блокировки для записи клиента росла, пока не закончились обновления. Обновления ожидания заняли общий пул работников, который начинает работу для всех клиентов в регионе, поэтому рабочие места каждого клиента ждали за ними. Механизм, предназначенный для изоляции нагрузки одного клиента, стал узким местом. ## Ответить Команда определила перегруженный путь приема и рабочую нагрузку за ним. Первое изменение конфигурации в 15:46 UTC нацелилось на неправильный рекорд и не имело эффекта. Правильное изменение в 16:10 UTC освободило тип работы клиента от блокировки базы данных и вступило в силу примерно в 16:20 UTC. Время начала работы сократилось с 13 секунд до менее одной секунды, а отставание в 5200 рабочих мест сократилось за 18 минут. Начало работы было нормальным в 16:38 UTC. Триггер клиента был выключен с клиентом примерно в 16:40 UTC. ##Продолжение Ограничение скорости, блокируемое базой данных, заменяется механизмом ограничения высокой производительности в памяти, поэтому нагрузка одного клиента не может блокировать начало работы для других. Изменение завершено, проверено в предварительном производстве при той же нагрузке и развертывается.

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

1. 2 октября 2026 г. в 00:13 UTCinvestigating

   В настоящее время мы расследуем отключение, затрагивающее портал Insights в регионе ОАЭ. Пользователи в этом регионе могут быть не в состоянии получить доступ к порталу или могут испытывать неисправную загрузку страницы. Наша команда активно работает над выявлением причины и восстановлением сервиса. Мы предоставим еще одно обновление, как только у нас будет больше информации.

2. 2 октября 2026 г. в 00:36 UTCidentified

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

3. 2 октября 2026 г. в 00:41 UTCmonitoring

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

4. 2 октября 2026 г. в 00:51 UTCresolved

   Портал Insights в регионе ОАЭ теперь работает в обычном режиме после отката. Мы проверили функциональность ключевого портала и подтвердили, что сервис остается здоровым. Теперь этот инцидент урегулирован.

5. 5 октября 2026 г. в 22:58 UTCpostmortem

   ##Влияние на клиента 1 октября 2026 года служба UiPath Insights в регионе ОАЭ была недоступна. Примерно с **23:40 UTC 1 октября до 00:39 UTC 2 октября** пользователи не могли загрузить панели мониторинга Insights: запросы не сработали с ошибкой примерно через 10 секунд. Запросы на предоставление Insights для новых арендаторов в регионе также провалились. Разрыв длился примерно **59 минут**. Другие услуги UiPath в регионе ОАЭ и Insights во всех других регионах не пострадали. Данные клиентов не были потеряны. ##Коренная причина Отключение было вызвано изменением конфигурации **, которое было отправлено в запланированном выпуске Insights. Изменение повысило ** минимальную версию TLS \(Transport Layer Security\)** на конечных точках приложения Insights в регионе ОАЭ с TLS 1.2 до **TLS 1.3** в рамках усилий по укреплению безопасности. Шлюз UiPath, который направляет трафик клиентов в Insights, соединяется с этими конечными точками через TLS 1.2. После того, как конечные точки перестали принимать TLS 1.2, шлюз больше не мог открывать безопасное соединение с ними. Запросы клиентов были отсрочены и вернули ошибки, хотя само приложение Insights оставалось здоровым. Изменения коснулись только региона ОАЭ, поэтому ни один другой регион не пострадал. ## Обнаружение Проблема была обнаружена автоматическим синтетическим мониторингом **UiPath, который постоянно проверяет доступность Insights из нескольких мест. Первая неудачная проверка здоровья была зарегистрирована в 23:40 UTC. Автоматизированные оповещения были выпущены в течение нескольких минут, и команда инженеров начала расследование. ## Ответить Инженерная группа подтвердила, что отключение затронуло только Insights в регионе ОАЭ. Приложение работало нормально, но трафик клиентов не достигал его. Команда проследила отказ до этапа безопасного соединения между шлюзом и Insights и связала его с настройками TLS, применяемыми релизом. Примерно в 00:38 UTC команда восстановила предыдущую минимальную версию TLS \(TLS 1.2\) на пораженных конечных точках. Синтетические проверки здоровья начали проходить немедленно, и к 00:41 UTC все проверки Insights в регионе ОАЭ были здоровыми. Команда продолжала мониторинг, чтобы подтвердить полную стабильность. ##Поддержка Чтобы предотвратить подобные инциденты в будущем, мы предпринимаем следующие шаги: Удалите изменение TLS из выпуска **, чтобы будущие развертывания не повторно применяли его, пока шлюз не поддержит TLS 1.3. *** Проверить изменения безопасности подключения к шлюзу** в предпроизводственной среде до их применения к производству.

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

1. 1 октября 2026 г. в 18:57 UTCinvestigating

   Начиная с 1 октября примерно в 1:30 вечера по Гринвичу, некоторые Агенты, включая агенты с низким кодом и закодированные агенты, начали испытывать сбои во всех регионах при использовании gemini-3.1-pro-preview и gpt-4o-2024-05-13. Эти модели также могут быть недоступны для выбора при проектировании агентов. Мы активно расследуем и работаем над исправлением.

2. 1 октября 2026 г. в 19:05 UTCidentified

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

3. 1 октября 2026 г. в 19:46 UTCresolved

   Мы вернули изменения, которые вызвали эту проблему, и подтвердили, что затронутые модели снова доступны. Некоторые агенты могут продолжать испытывать периодические сбои, в то время как случаи обновляются. Мы продолжаем следить за разработкой и исполнением агентов для gemini-3.1-pro-preview и gpt-4o-2024-05-13.

4. 7 октября 2026 г. в 10:15 UTCpostmortem

   ##Воздействие на клиента 1 октября 2026 года, с 14:31 до 19:40 UTC, агенты, сконфигурированные с некоторыми крупными языковыми моделями, включая Gemini 3.1 Pro Preview и GPT-4o (2024-05-13), не смогли запустить во всех регионах, с ошибкой заявив, что модель недоступна. Те же модели отсутствовали в списке моделей при проектировании агентов. Агенты, использующие другие модели, не пострадали. ##Коренная причина Флаг функции был перевернут, в результате чего служба Агентов начала отправлять код операции для моделирования запросов на обнаружение. Это привело к тому, что список моделей служил для этой конкретной операции, а не для базовых агентов. Список моделей для каждой операции был первоначально засеян конфигурацией переопределяемых моделей Bring Your Own Model (BYOM), которая не имела паритета с полным списком поддерживаемых моделей в службе Агентов. Внутренний аудит показал, что это была ошибка, а не преднамеренный пробел. Со временем этот разрыв так и не был устранен, и после переключения флага агенты, уже настроенные на любую из затронутых моделей, потерпят неудачу из-за их отсутствия в возвращенном списке. ## Обнаружение Клиент сообщил о проблеме, и она была передана нашим инженерам в 16:44 UTC. Наш мониторинг не предупредил, потому что эта ошибка обычно указывает на проблемы с конфигурацией уровня организации или агента. ## Ответить Инженеры отследили сбои до изменения конфигурации и вернули его в 19:01 UTC. Обратный эффект наступил в течение следующих минут, а последний сбой произошел в 19:40 UTC. ##Продолжение 1.Списки моделей будут выровнены до того, как это изменение будет произведено снова. 2. Мы меняем способ классификации этой ошибки, так что шип всей платформы предупреждает наших инженеров.

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

1. 1 октября 2026 г. в 18:17 UTCinvestigating

   Начиная с 1 октября примерно в 12:00 UTC пользователи сообщества в Европе могут испытывать сбои в работе агентов LowCode, которые используют приложения Action. Мы подтвердили, что влияние ограничено пользователями сообщества в Европе. Мы активно расследуем вопрос, определяем масштабы сбоев и работаем над исправлением.

2. 1 октября 2026 г. в 18:25 UTCidentified

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

3. 1 октября 2026 г. в 20:08 UTCresolved

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

4. 7 октября 2026 г. в 14:28 UTCpostmortem

   ##Воздействие на клиента 1 октября 2026 года, с 10:50 до 19:50 UTC, некоторые пользователи Studio Web в Европе не могли отлаживать агенты, которые вызывают процессы Orchestrator (RPA, агенты и т. д.) или Action Apps из того же решения. Звонок провалился с ошибкой «не найден». Опубликованные агенты и производственные рабочие места не пострадали. ##Коренная причина Обновление Studio Web изменило расположение ресурсов решения во время отладки. В нем отсутствовала настройка, которая сохраняет прежнее поведение, поэтому отладчики искали ресурсы решения в личном рабочем пространстве пользователя вместо папки отладки. ## Обнаружение Автоматизированные сквозные испытания оповещали наших инженеров в 16:43 UTC. Комплекс сквозного тестирования работает один раз в 2 часа, а оповещение происходит только после 3 последовательных сбоев в тестировании. О проблеме также сообщалось из клиентской среды. ## Ответить После выявления первопричины откат был начат в 18:00 UTC и полностью вступил в силу в 19:50 UTC. Эта продолжительность включала отказ развертывания, который должен был быть исправлен, что заняло 50 минут. Исправленная версия, включающая настройку, была развернута 2 октября в 13:00 UTC. ##Продолжение 1.Настройка теперь является частью основной строки кода, поэтому будущие релизы включают ее. 2. Мы улучшаем оповещения и комплексное тестирование, чтобы поймать регрессии раньше.

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

1. 1 октября 2026 г. в 16:32 UTCresolved

   Между 14:23 и 16:04 UTC 1 октября 2026 года некоторые запросы на удаление элементов в облачных сервисах UiPath Automation Cloud в австралийском регионе потерпели неудачу с ошибками «404 Not Found». Среди затронутых услуг были Orchestrator, Document Understanding, AI Center и Data Service. Другие операции, такие как просмотр, создание и обновление элементов, работали нормально. Причиной стало изменение конфигурации маршрутизации наших запросов. Мы его откатили и сервис полностью восстановлен.

2. 7 октября 2026 г. в 10:15 UTCpostmortem

   ##Воздействие на клиента В период с 1 октября 2026 года в 2:23 вечера по UTC и 4:04 вечера по UTC подмножество клиентов испытало ошибки **404 Not Found** для некоторых запросов UiPath Automation Cloud в регионе Австралии. Инцидент продолжался 1 час 41 минуту. Пострадавшие запросы включали операции удаления и некоторые проверки подключения робота. В число затронутых сервисов вошли Orchestrator, Document Understanding, AI Center и Data Service. Роботы, которые называются Orchestrator, возможно, потерпели неудачу, и клиентам, возможно, потребуется повторно запустить любые роботы, которые потерпели неудачу во время этого окна. Все остальные операции не пострадали. ##Коренная причина Изменение конфигурации маршрутизации было применено к региону Австралии с неполным набором поддерживаемых операций из-за тайм-аута в трубопроводе выпуска. Операции удаления отсутствовали в конфигурации, поэтому эти запросы были отклонены на уровне маршрутизации с **404 Not Found ** до достижения базовых служб. ## Обнаружение Автоматизированный сквозной мониторинг выявил проблему, предупредив о сбоях в проверках сервиса Document Understanding. Затем наша команда инженеров использовала данные внутреннего мониторинга, чтобы подтвердить более широкую картину сбоев в пострадавших службах. ## Ответить В ходе расследования данные мониторинга показали, что запросы, направляемые через австралийский регион, возвращали ошибки **404 Not Found**, в то время как запросы, направляемые через другие регионы, не затрагивались. Анализ показал, что время начала **404 Not Found** увеличения отклика коррелировало со временем вступления в силу конфигурации маршрутизации. Команда изменила конфигурацию маршрутизации на предыдущую рабочую версию. После реверса мониторинг показал, что количество ошибок падает примерно через три минуты, и служба была полностью восстановлена к 1 октября 2026 года в 4:04 вечера UTC. ##Продолжение 1. Улучшить уровень оповещения о начальных изменениях 4xx 2. Обнаружение частично применяемых конфигураций маршрутизации до их вступления в силу

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