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

1. 21 октября 2026 г. в 14:48 UTCinvestigating

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

2. 21 октября 2026 г. в 16:03 UTCresolved

   Мы рады сообщить вам, что инцидент, затрагивающий службу инвентаризации, был устранен. Наша команда внедрила исправление, и все системы теперь работают нормально. Мы приносим извинения за любые неудобства, вызванные этим инцидентом, и мы ценим ваше понимание и поддержку. По любым вопросам или проблемам обращайтесь в нашу службу поддержки по адресу https://support.delinea.com.

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

1. 13 октября 2026 г. в 15:42 UTCinvestigating

   Начиная примерно с 12:32 UTC 13 октября 2026 года, некоторые пользователи, подписавшиеся на платформу Delinea с одним входом SAML (SSO), не смогли завершить вход и получили сообщение «Отказ в доступе — ошибка 15» после аутентификации со своим поставщиком идентификационных данных. Пользователи, которые уже вошли, и пользователи, которые вошли без SAML SSO, не пострадали. Проблема была вызвана правилом безопасности у стороннего провайдера пограничной сети, который неправильно заблокировал ответы SAML. Наша инженерная команда применила изменение конфигурации в 14:11 UTC, и с тех пор логины SAML SSO успешно работают. Если вы продолжаете испытывать эту ошибку, пожалуйста, обновите свой браузер и попробуйте снова. Мы приносим извинения за причиненные неудобства и ценим ваше терпение, поскольку мы работали над восстановлением нормального обслуживания. По любым вопросам об этом инциденте обращайтесь в нашу службу поддержки по адресу https://support.delinea.com.

2. 13 октября 2026 г. в 15:44 UTCidentified

   Этот вопрос был определен, и в настоящее время осуществляется исправление.

3. 13 октября 2026 г. в 15:49 UTCmonitoring

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

4. 13 октября 2026 г. в 16:02 UTCmonitoring

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

5. 13 октября 2026 г. в 16:56 UTCresolved

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

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

1. 15 октября 2026 г. в 08:30 UTCresolved

   Примерно в 9:13 вечера 13 октября 2026 года некоторые клиенты испытывали преждевременные отключения при запуске сеансов удаленного приложения PRA. Сеансы заканчивались примерно через 2-3 минуты. Недавнее обновление библиотеки FreeRDP ввело ошибку регрессии, которая опустила рукопожатие клиента RAIL (Remote Applications Integrated Locally) во время сеансов удаленного приложения. Без этого рукопожатия целевой хост относился к сеансу как к неактивному и прекращал его после настроенного простоя. Разрешение: движок PRA был исправлен для восстановления рукопожатия клиента RAIL для удаленных подключений приложений. Исправление было развернуто, и связь была восстановлена для пострадавших клиентов примерно в 12:34 вечера 14 октября 2026 года. Пострадавшие компоненты: Платформа: Привилегированный удаленный доступ - США, SEA, Великобритания и регионы АС Уведомление об обратном заполнении: этот инцидент был добавлен на нашу страницу статуса ретроспективно, чтобы обеспечить точную запись о влиянии сервиса. Более подробная информация об инцидентах с обратным заполнением доступна здесь.

2. 20 октября 2026 г. в 23:36 UTCpostmortem

   ##Обзор инцидентов Подмножество клиентов, использующих сеансы удаленного доступа (PRA), испытали отключение сеанса примерно через 2-3 минуты после запуска. Отчеты были получены от клиентов в регионах SEA, AU, ОАЭ, CA, Великобритании и США. ** Начало:** 13 октября 2026, 21:13 UTC ** Конец:** 14 октября 2026, 19:28 UTC ##Коренная причина и восстановление Запланированное обновление было развернуто на региональном уровне в нашей службе удаленных сеансов в рамках текущей работы по соблюдению требований безопасности. Это обновление включало новую версию стороннего компонента протокола удаленного рабочего стола, который ввел изменение поведения, которое предотвратило завершение рукопожатия конкретного соединения во время инициализации сеанса. В результате пострадавшие сеансы автоматически отключались примерно через 2-3 минуты после успешного подключения. Поскольку эти отключения были завершены без ошибок в системных журналах или следов, проблема не была обнаружена существующими системами мониторинга до первого отчета клиента 13 октября 2026 года. Исправление для восстановления необходимого соединения рукопожатия было выявлено и развернуто во всех пострадавших регионах примерно в 19:28 по UTC 14 октября 2026 года. ##Профилактические меры * Расширьте охват нашего автоматизированного дистанционного тестирования приложений, чтобы включить длительные сессии, поэтому перед выпуском возникают проблемы, зависящие от времени. Добавьте мониторинг аномалий продолжительности сеанса, в частности, отслеживание сеансов, которые отключаются через последовательные короткие интервалы (например, от 2 до 3 минут), даже когда отключение кажется чистым. Мы искренне извиняемся за причиненный ущерб и ценим ваше терпение, пока мы работали над его устранением.

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

1. 13 октября 2026 г. в 15:26 UTCresolved

   Между 12:32 UTC и 14:11 UTC 13 октября 2026 года некоторые пользователи, подписавшиеся на платформу Delinea с одним входом SAML (SSO), не смогли завершить вход в систему и получили сообщение «Отказ в доступе — ошибка 15» после аутентификации со своим поставщиком идентификационных данных. Пользователи, которые уже вошли, и пользователи, которые вошли без SAML SSO, не пострадали. Проблема была вызвана правилом безопасности у стороннего провайдера пограничной сети, который неправильно заблокировал ответы SAML. Наша инженерная команда применила изменение конфигурации в 14:11 UTC, и с тех пор логины SAML SSO успешно работают. Если вы продолжаете испытывать эту ошибку, пожалуйста, обновите свой браузер и попробуйте снова. Мы приносим извинения за причиненные неудобства и ценим ваше терпение, поскольку мы работали над восстановлением нормального обслуживания. По любым вопросам об этом инциденте обращайтесь в нашу службу поддержки по адресу https://support.delinea.com. Пострадавшие компоненты: платформа Delinea - США, Европа, Великобритания, Канада, Австралия, Юго-Восточная Азия, Объединенные Арабские Эмираты Уведомление об обратном заполнении: этот инцидент был добавлен на нашу страницу статуса ретроспективно, чтобы обеспечить точную запись о влиянии сервиса. Более подробная информация об инцидентах с обратным заполнением доступна здесь.

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

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

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

2. 1 октября 2026 г. в 22:09 UTCmonitoring

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

3. 2 октября 2026 г. в 00:25 UTCresolved

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

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

   ##Обзор инцидентов 1 октября 2026 года у клиентов в регионе ЕС возникли проблемы с использованием Secret Server Cloud (SSC). Пользователи не могли запускать сеансы из секретов, а страницы для просмотра секретных деталей и истории аудита загружались медленно или проваливались. Запланированные фоновые задачи, такие как сердцебиение, изменение пароля, обнаружение и уведомления, были отложены, а некоторые распределенные движки не могли подключиться. * Время начала: 1 октября 2026, 08:38 PM UTC Время окончания: 2 октября 2026, 12:30 AM UTC ##Коренная причина и восстановление SSC использует службу обмена сообщениями для передачи работы между ее компонентами. Примеры включают запись секретной активности просмотра для аудита, выполнение запланированных задач и подготовку запусков сеансов. 30 сентября 2026 года сервис SSC, обрабатывающий эти сообщения в регионе ЕС, начал обрабатывать работу гораздо более низкими темпами, чем обычно. Новая активность продолжала прибывать с нормальной скоростью, поэтому в очереди появлялись необработанные сообщения. Когда очередь достигла своей пропускной способности, дополнительные сообщения были перемещены в зону хранения для недоставляемых сообщений. В течение следующих часов эта зона хранения продолжала расти, пока служба обмена сообщениями не достигла предела хранения. Наша инженерная команда увеличила пропускную способность службы обмена сообщениями, расширила и перезапустила службы SSC EU, а также устранила отставание от недоставляемых сообщений. После того, как накопилось отставание, запуски сеансов, загрузка страниц и запланированные задачи вернулись к норме к 2 октября 2026 года, 12:30 утра по UTC. Отложенные фоновые задачи, включая сердцебиение, изменение пароля и уведомления, обрабатывались автоматически после восстановления сервиса. Клиентам не нужно было предпринимать никаких действий. Поскольку сервисы были немедленно восстановлены для прекращения воздействия на клиентов, мы не собрали диагностические данные, необходимые для определения того, почему их пропускная способность снизилась, поэтому основной триггер остается неизвестным. Рост очередей должен был быть пойман раньше. Во время недавней миграции нашего инструмента оповещения изменение конфигурации отправило определенные облачные метрические оповещения, включая оповещение о размере очереди сообщений, в неправильное место назначения. Это предупреждение сработало утром 1 октября, но мы не уведомили нашу команду по вызову. Автоматическое восстановление для других типов оповещений не было затронуто, что замаскировало пробел. ##Профилактические меры 1.Мы исправили маршрут оповещения 2 октября 2026 года, поэтому эти оповещения теперь поступают в нашу команду по вызову, и мы добавляем канарейки и предупреждения о сердцебиении, которые уведомляют нас, если доставка оповещения из наших инструментов мониторинга неожиданно прекращается или падает. 2.Мы усиливаем процесс изменения системы оповещения, проверяя каждый тип оповещения до и после развертывания производства. 3.Мы отслеживаем повторение замедления и будем собирать диагностические данные, необходимые для определения его причины, если это произойдет снова. 4.Мы обновляем наш цикл развертывания с гарантией, которая обеспечивает обновление фоновых служб даже при задержке выпуска, и мы добавляем этот шаг в наш контрольный список выпуска. Мы приносим извинения за причиненный ущерб и ценим ваше терпение, пока мы решаем эту проблему.

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

1. 29 сентября 2026 г. в 01:02 UTCidentified

   Мы расследуем сообщения о медленном входе в систему и периодических сбоях входа для клиентов платформы Delinea в регионах ЕС, Великобритании, Юго-Восточной Азии и Австралии. Начиная примерно с 23:20 по 28 сентября 2026 года, некоторым пользователям может потребоваться гораздо больше времени, чем обычно. Некоторые попытки входа могут потерпеть неудачу с тайм-аутом или ошибкой HTTP 504. Пользователи, которые уже подписаны, также могут видеть более медленные ответы при проверке сеанса. Наша инженерная команда активно занимается и определила деградировавшую зависимость, влияющую на службу аутентификации в этих регионах. Сейчас мы работаем над смягчением. Если вход не удался, пожалуйста, повторите. Мы опубликуем еще одно обновление в течение 30 минут или раньше, если у нас будет новая информация.

2. 29 сентября 2026 г. в 01:14 UTCidentified

   Мы применили исправление для клиентов в регионах ЕС и Австралии. Показатели входа и ошибок в этих регионах вернулись к норме примерно с 01:05 UTC 29 сентября 2026 года. Мы проводим мониторинг, чтобы подтвердить, что восстановление продолжается.

3. 29 сентября 2026 г. в 01:19 UTCmonitoring

   Мы применили исправление для всех пострадавших регионов: ЕС, Великобритании, Юго-Восточной Азии и Австралии. Показатели входа и ошибок вернулись к норме примерно с 01:10 UTC 29 сентября 2026 года. Мы проводим мониторинг, чтобы подтвердить, что восстановление продолжается. Если у вас все еще есть проблемы с входом, пожалуйста, обновите свой браузер и попробуйте снова. Если проблема не решена, обратитесь в службу поддержки Delinea.

4. 29 сентября 2026 г. в 01:35 UTCresolved

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

5. 6 октября 2026 г. в 01:00 UTCpostmortem

   ##Обзор инцидентов Пользователи платформы Delinea в регионах ЕС, Великобритании, Юго-Восточной Азии и Австралии испытывали очень медленные входы и периодические сбои входа. Затронутая функциональность включала в себя единый вход Entra ID, аутентификацию локальной учетной записи и создание сеанса привилегированного удаленного доступа \(PRA\). * Начало: 28 сентября 2026, приблизительно 11:20 вечера UTC * Конец: 29 сентября 2026, приблизительно 01:10 AM UTC ##Коренная причина и восстановление Запланированное развертывание привело к использованию региональных реплик кэша для повышения производительности аутентификации. Предварительная проверка подтвердила, что реплики были активны, но ошибка конфигурации брандмауэра помешала синхронизации данных между основным кэшем и региональными репликами. Стандартные отчеты о состоянии здоровья облачного провайдера продолжали показывать, что реплики являются здоровыми и доступными, поэтому проблема не была выявлена до или во время выпуска. Когда служба аутентификации попыталась прочитать эти реплики, запросы застопорились и отсрочились, что привело к сбоям входа в систему. Внутренний мониторинг выявил повышенные показатели ошибок, а команда инженеров определила первопричину и отменила изменение. Откат вернул все пораженные участки в первичный кэш и восстановил нормальную аутентификацию. Региональные кэш-копии останутся отключенными для регионов ЕС, Великобритании, Юго-Восточной Азии и Австралии, пока мы оцениваем альтернативные архитектуры. Мы оценили связь между кэшами и определили, что она не соответствует нашим требованиям к надежности. ##Превентивные меры Мы вносим значительные улучшения в то, как служба аутентификации восстанавливается после проблем с подключением кэша. Цель состоит в том, чтобы деградировавшее соединение кэша больше не вызывало застопорившихся или неудавшихся логинов. Мы добавили альтернативный мониторинг сбоев соединения, давая раннее обнаружение проблем, связанных с кэшем, которые не отражены в отчетах о состоянии здоровья облачного провайдера. Мы приносим извинения за нарушения и стремимся предотвратить повторение этих мер.

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

1. 28 сентября 2026 г. в 21:35 UTCinvestigating

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

2. 29 сентября 2026 г. в 19:53 UTCidentified

   Вопрос был определен, и над ним ведется работа. Для исправления потребуется новое развертывание во время окна обслуживания в выходные дни. Тем временем, пожалуйста, обратитесь к приведенной ниже статье KB для получения подробной информации по этому вопросу и способам его решения. https://support.delinea.com/s/article/1790702420275 Спасибо за ваше терпение. Если у вас есть какие-либо вопросы или возникли какие-либо проблемы, пожалуйста, откройте дело по адресу https://support.delinea.com или позвоните в нашу службу поддержки по телефону +1 202-991-0540.

3. 6 октября 2026 г. в 13:21 UTCresolved

   Мы рады сообщить вам, что инцидент, затрагивающий перечисленные ниже услуги, был устранен. Наша команда внедрила исправление, и все системы теперь работают нормально. Мы приносим извинения за любые неудобства, вызванные этим инцидентом, и мы ценим ваше понимание и поддержку. По любым вопросам или проблемам обращайтесь в нашу службу поддержки по адресу https://support.delinea.com.

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

1. 30 сентября 2026 г. в 08:07 UTCresolved

   В период с 4:10 по 6:45 по 28 сентября 2026 года некоторые клиенты не смогли подключиться к Secret Server Cloud из определенных корпоративных сетей. Пострадавшие пользователи видели ошибки сброса соединения или тайм-аута при доступе к своему арендатору. Доступ из других сетей не пострадал. Клиенты, которые ограничивают доступ арендатора к определенным IP-адресам, не смогли войти в систему в течение этого периода. Проблема была вызвана проблемой подключения к стороннему провайдеру пограничных сетей, которая повлияла на трафик из некоторых клиентских сетей в регионе. Трафик был направлен через альтернативные места, и связь была восстановлена для пострадавших клиентов примерно в 6:45 утра по восточному времени. Мы приносим извинения за причиненные неудобства и ценим ваше терпение, поскольку мы работали над восстановлением нормального обслуживания. По любым вопросам об этом инциденте обращайтесь в нашу службу поддержки по адресу https://support.delinea.com. Пострадавшие компоненты: Secret Server Cloud - Европа, Великобритания, США, Азиатско-Тихоокеанский регион (Сингапур) Уведомление об обратном заполнении: этот инцидент был добавлен на нашу страницу статуса ретроспективно, чтобы обеспечить точную запись о влиянии сервиса. Более подробная информация об инцидентах с обратным заполнением доступна здесь.

2. 30 сентября 2026 г. в 08:48 UTCpostmortem

   ##Обзор инцидентов Начиная с 07:10 UTC 28 сентября 2026 года, подмножество арендаторов Secret Server Cloud в Европе, Великобритании, США и Азиатско-Тихоокеанском регионе испытали сбои подключения. Клиенты в определенных корпоративных сетях сталкиваются с тайм-аутами подключения или ошибками сброса при попытке связаться со своими арендаторами. Клиенты с включенными ограничениями доступа арендаторов не имели альтернативного пути и не могли получить доступ к Облаку секретного сервера в течение всего инцидента. * Старт: 28 сентября 2026, 07:10 UTC * Конец: 28 сентября 2026, 10:45 UTC ##Коренная причина и восстановление Сеть Secret Server Cloud испытывала две отдельные проблемы, которые мешали трафику из некоторых клиентских сетей достигать своих арендаторов. Первый был связан с дефектом в обновлении программного обеспечения, которое развернул наш провайдер. В соответствии с конкретным производственным условием, которое не было выявлено в ходе предварительного тестирования поставщика, дефект вызвал перезапуск компонентов обработки трафика в нескольких местах его сети. Эти компоненты восстанавливались автоматически, и обслуживание в пострадавших местах было восстановлено между 07:47 и 08:20 UTC. Во-вторых, из-за проблемы с интернет-провайдером, затрагивающей нашу пограничную сеть в Лондоне, произошла потеря пакетов и время ожидания соединения. В результате сети клиентов, чей трафик направлялся через Лондон, продолжали подвергаться воздействию после того, как первая проблема была устранена. Соединение было полностью восстановлено в 10:45 UTC после того, как трафик был перенаправлен от пострадавшего перевозчика. ##Превентивные меры Поставщик развернул исправление дефекта программного обеспечения и усиливает его валидацию перед развертыванием, устойчивость своей инфраструктуры в разных местах и автоматизированные механизмы восстановления. Мы отслеживаем эти обязательства до конца. Мы проводим полный обзор проблемы лондонского перевозчика с нашим провайдером, в том числе, почему трафик не был перенаправлен раньше, и сокращаем время отказа, поэтому будущие сбои перевозчика быстро изолируются. Мы искренне извиняемся за срыв, который это вызвало, и неудобства для ваших операций. Мы стремимся предотвратить повторение этих действий.

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

1. 22 сентября 2026 г. в 12:11 UTCinvestigating

   Мы расследуем проблему, затрагивающую логин и доступ к Secret Server Cloud для подмножества клиентов в регионах США, ЕС и ОАЭ. Наша инженерная команда активно изучает этот вопрос и работает над его решением как можно быстрее.

2. 22 сентября 2026 г. в 12:58 UTCmonitoring

   Мы продолжаем следить за дальнейшими вопросами

3. 22 сентября 2026 г. в 13:07 UTCresolved

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

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

1. 16 сентября 2026 г. в 16:37 UTCinvestigating

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

2. 16 сентября 2026 г. в 16:50 UTCidentified

   Этот вопрос был определен, и в настоящее время осуществляется исправление.

3. 16 сентября 2026 г. в 17:02 UTCmonitoring

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

4. 16 сентября 2026 г. в 17:22 UTCmonitoring

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

5. 16 сентября 2026 г. в 18:32 UTCresolved

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

6. 24 сентября 2026 г. в 21:50 UTCpostmortem

   ##Обзор инцидентов 16 сентября 2026 года клиенты Delinea Platform в регионе США испытали сбои входа в систему и сильную медлительность при входе в систему или доступе к своим арендаторам. Пострадавшие пользователи могли видеть ошибки «тайм-аута» на экране входа или испытывать длительные задержки при загрузке своего арендатора. ** Начало:** 16 сентября 2026 года приблизительно в 11:40 утра по восточному времени (UTC-4) ** Конец:** 16 сентября 2026 года приблизительно 1:02 PM EDT \(UTC-4\) ##Коренная причина и восстановление Платформа Delinea использует сервис кэширования для поддержки входа в систему, аутентификации и других операций, связанных с идентификацией. В течение предыдущих недель спрос на эту услугу в регионе США неуклонно рос с увеличением использования платформы, оставляя ограниченные операционные возможности. Кроме того, службы аутентификации держали соединения со службой кэширования открытыми с течением времени, а не выпускали их, что постепенно потребляло его доступную емкость. Конфигурация, которая распределяет трафик чтения через дополнительный ресурс кэширования, который обеспечил бы дополнительный запас хода, в то время не была активной. 16 сентября нормальные объемы трафика вытеснили сервис кэширования за пределы его операционной мощности, что привело к медленным и неудавшимся запросам на логин и операции идентификации по всему региону США. Этот инцидент связан с той же инфраструктурой кэширования, что и инцидент 28 августа 2026 года (https://status.delinea.com/incidents/1s7gw9kyjwyq). Этот инцидент был вызван необычно большим объемом синхронизации и был устранен путем увеличения емкости памяти службы кэширования. Этот инцидент произошел при нормальных условиях движения, которые показали, что необходимо также решить проблему вычислительной мощности и обработки соединений. Наша инженерная команда перезапустила затронутые службы аутентификации, которые выпустили накопленные соединения и восстановили функциональность входа в систему. Сервис кэширования также был масштабирован до более высокого уровня, что удваивает его вычислительную мощность, и мы продолжали следить за сервисом, пока не было подтверждено полное восстановление. После инцидента использование кэширования оставалось в пределах обычных операционных порогов, и трафик чтения теперь распределяется по дополнительному ресурсу кэширования. ##Профилактические меры После инцидента 28 августа 2026 года мы взяли на себя обязательство по нескольким улучшениям этой инфраструктуры кэширования. Ниже приведен прогресс по каждому из них, а также дополнительные действия, выявленные в результате этого инцидента. Работа по всем пунктам продолжается. **Прогресс в отношении действий в связи с инцидентом 28 августа** ** Увеличить пропускную способность и отказоустойчивость нашей кэширующей инфраструктуры.** Служба кэширования в США была масштабирована до более высокого уровня, что удваивает ее вычислительную мощность. Трафик чтения теперь распределяется по дополнительному ресурсу кэширования. Мы продолжаем эту работу, перемещая операции, связанные с токенами, в специализированную инфраструктуру кэширования для дальнейшего использования. ** Правильные пороги мониторинга для проактивного обнаружения давления пропускной способности.** Во время этого инцидента наш мониторинг выявил давление пропускной способности перед воздействием на клиента, но оповещения не были приняты вовремя. Мы продолжаем эту работу, удаляя недействующие оповещения для основных служб аутентификации и требуя немедленного участия инженеров в первом оповещении. ** Ограничить повторные попытки восстановления соединения.** Эта работа была расширена, чтобы охватить то, как службы аутентификации управляют кэширующими соединениями в целом, включая настройки выпуска соединения и тайм-аута, поэтому емкость постепенно не потребляется с течением времени. *** Ставка приложения, ограничивающая большие рабочие места синхронизации.** Осуществляется ограничение ставок. Мы также сокращаем ненужные запросы большого объема от интегрированных сервисов до уровня кэширования. ** Дополнительные действия в связи с этим инцидентом** Внедрение запланированных автоматических перезапусков служб аутентификации в качестве временной гарантии до тех пор, пока не будут развернуты улучшения обработки соединения. Мы признаем, что это не первое нарушение регистрации на платформе Delinea за последние недели, и мы не относимся к этому легкомысленно. Помимо вышеперечисленных действий, руководство Delinea сделало надежность нашей Платформы приоритетом, спонсируемым руководством, в преддверии функциональной работы, где они конкурируют. Это включает в себя лучшее выявление проблем, влияющих на критические рабочие процессы, такие как вход в систему и потенциал планирования в преддверии роста. Мы искренне извиняемся за срыв, который это вызвало в вашей деятельности, и будем продолжать делиться нашим прогрессом.

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

1. 4 сентября 2026 г. в 22:02 UTCresolved

   Этот инцидент был урегулирован. Мы приносим извинения за срыв, который это вызвало. расследовать Мы расследуем сообщения о том, что арендаторы платформы Delinea отображают замороженное сообщение арендатора, не позволяя пользователям войти и получить доступ к своей среде. Состояние началось примерно в 4:49 вечера по восточному времени из-за неправильного изменения конфигурации, что не позволило некоторым клиентам получить доступ к своим арендаторам. Инженеры определили причину, провели обратную работу, начиная примерно с 5:08 вечера по восточному времени, и все пострадавшие арендаторы были подтверждены незамороженными к 5:55 вечера по восточному времени. Уведомление об обратном заполнении: этот инцидент был добавлен на нашу страницу статуса ретроспективно, чтобы обеспечить точную запись о влиянии сервиса. Более подробная информация об инцидентах с обратным заполнением доступна здесь.

2. 25 сентября 2026 г. в 05:05 UTCpostmortem

   ## Incident Overview This report covers two related occurrences that affected Delinea customer tenants. The second occurrence, September 19-20, 2026, was a direct consequence of incomplete recovery from the first occurrence on September 4, 2026, and both are documented together under this incident. #### Occurrence 1: September 4, 2026 A subset of Delinea Platform tenants entered a frozen state, displaying a tenant frozen message that prevented users from signing in and accessing Delinea Platform and Secret Server Cloud. **Start:** September 4, 2026, 4:15 PM EDT \(20:15 UTC\) **End:** September 4, 2026, 5:55 PM EDT \(21:55 UTC\) #### Occurrence 2: September 19-20, 2026 A subset of Secret Server Cloud tenants displayed a scheduled for deletion notice that prevented users from signing in to Secret Server Cloud. Sign-in to Delinea Platform itself remained available. **Start:** September 19, 2026, 10:28 PM EDT \(September 20, 02:28 UTC\) **End:** September 20, 2026, 1:50 PM EDT \(17:50 UTC\) ## Root Cause and Remediation #### Occurrence 1: September 4, 2026 Delinea deprovisions tenants that are no longer under an active subscription. The tenant list for this cycle was built using selection criteria that evaluated only the original subscription expiration date and did not account for subsequent renewals. As a result, tenants that had renewed and remained fully entitled were treated as expired and were included in the list alongside legitimate deprovisioning tenants. Our deprovisioning workflow includes a customer-facing advance notification stage, which displays an in-application notice to tenant administrators ahead of any deletion activity. That notice serves both as a customer warning and as an internal verification step, because any active customer receiving it would have surfaced the error well before execution. This stage was not applied for this cycle; the frozen state was applied directly instead, so the error in the selection criteria went undetected until the job ran. When the scheduled job executed at 4:15 PM EDT, the frozen tenant state was applied to the affected active tenants. Following the first customer report at 4:49 PM EDT, Engineering identified the cause and initiated a revert job at 5:08 PM EDT. The revert completed at 5:55 PM EDT and sign-in access was confirmed restored across all affected tenants. However, the September 4 change had also set the subscription end date for affected Secret Server Cloud tenants to August 20, 2026. The revert restored tenant access but did not return those end dates to their correct values, and post-recovery verification confirmed sign-in access only, not the accuracy of the underlying subscription records. This condition remained undetected and led directly to Occurrence 2. #### Occurrence 2: September 19-20, 2026 Secret Server Cloud includes a standard automated lifecycle process that restricts sign-in and schedules a tenant for deletion 30 days after its subscription end date. On September 19, 2026, 30 days after the incorrect August 20, 2026 end date, this process identified the affected tenants as expired and applied the scheduled for deletion state. The lifecycle process behaved as designed; the fault was the incorrect subscription data left in place after Occurrence 1. Delinea Support began restoring access for individual tenants starting at 12:09 AM EDT on September 20. Engineering identified every tenant carrying the incorrect end date then extended the subscription end date for all affected tenants as a temporary measure, and access was restored across the full set by 1:50 PM EDT on September 20. Between September 21 and September 23, 2026, Delinea reviewed each affected tenant individually against its active entitlements and replaced the temporary end date with the correct value. During this period, some customers may have observed an inaccurate subscription end date or license detail in their account information; this did not affect access. If your organization observes a subscription end date or license detail that does not match your current entitlement, please contact our [Support team](https://support.delinea.com/s/). No tenant was deleted, and no customer data was deleted, modified, or otherwise affected in either occurrence. The impact was limited to tenant access. ## Preventative Actions * Bulk tenant deprovisioning has been retired. All bulk tenant lifecycle actions are paused, and deprovisioning will be processed individually. * Automate the tenant lifecycle end to end from current subscription records, including renewals and subscription changes, replacing the manual multi-step process. Each tenant will be validated against active subscription records before any state change is applied. * Make every lifecycle stage mandatory and non-skippable, beginning with an advance notice period during which tenant administrators see an in-application notice and all functionality continues to operate normally. * Ensure frozen tenants remain recoverable for a defined retention period before any permanent deletion, with restoration driven directly from corrected subscription records. * Strengthen incident recovery procedures so that any restoration of tenant state also restores and reconciles the associated subscription records, and recovery is verified against the system of record, not sign-in access alone, before an incident is closed. * Add internal monitoring and alerting for abnormal volumes of tenant freeze or scheduled for deletion events, and for anomalous patterns in subscription data, so that issues of this type are detected by Delinea before customers are affected. We sincerely apologize for the disruption caused by both occurrences. We recognize that the second occurrence resulted from our incomplete recovery from the first, which extended the impact on your operations. Restoring access was our immediate priority in each case, and the actions above are being tracked to completion to ensure this does not recur.

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

1. 28 августа 2026 г. в 18:02 UTCinvestigating

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

2. 28 августа 2026 г. в 18:27 UTCinvestigating

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

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

   Этот вопрос был определен, и в настоящее время осуществляется исправление.

4. 28 августа 2026 г. в 19:33 UTCmonitoring

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

5. 28 августа 2026 г. в 20:16 UTCresolved

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

6. 10 сентября 2026 г. в 00:54 UTCpostmortem

   ##Обзор инцидентов 28 августа 2026 года клиенты платформы Delinea в регионе США испытывали периодические сбои в входе и медленную производительность при входе или доступе к своим арендаторам, включая страницы ошибок или тайм-аута на экране входа для некоторых пользователей. В некоторых случаях повторная попытка входа в систему позволила пользователям успешно получить доступ к своему арендатору. * Начало: 28 августа 2026 приблизительно 17:29 UTC * Конец: 28 августа 2026 приблизительно 19:19 UTC ##Коренная причина и восстановление Изменение кода, связанное с кэшированием, которое было сделано 27 августа в сочетании с необычайно большим объемом фоновой синхронизации 28 августа, превысило нормальную операционную емкость нашей инфраструктуры кэширования, поддерживающей услуги входа в систему и аутентификации. Подключения к нему начали выходить из строя, и другие зависимые службы пытались восстановить эти соединения неоднократно, а не чисто, не позволяя кэширующей инфраструктуре стабилизироваться самостоятельно. Это привело к медленным или неудачным попыткам входа в систему и задержкам в операциях, связанных с идентификацией, в регионе США. Наша инженерная команда отменила изменение кэширования и перезапустила пострадавшие службы, которые очистили неисправные соединения и начали восстанавливать функциональность, хотя производительность оставалась ухудшенной. Ресурс кэширования был увеличен для восстановления нормальной работы. Мы продолжали внимательно следить за сервисом, пока не было подтверждено полное восстановление. ##Профилактические меры • Увеличить пропускную способность и отказоустойчивость нашей инфраструктуры кэширования путем распределения рабочих нагрузок по дополнительным ресурсам. Правильные пороги мониторинга для обеспечения проактивного обнаружения давления мощности до того, как оно повлияет на производительность платформы. Ограничьте повторные попытки восстановления соединения, чтобы предотвратить восстановление соединений от сложной нагрузки системы во время стрессового события. * Применять ставку, ограничивающую большие рабочие места синхронизации, чтобы предотвратить негативное влияние любой отдельной работы на производительность всей платформы. Мы искренне извиняемся за срыв, который это вызвало, и неудобства для ваших операций. Мы стремимся предотвратить повторение этих действий.

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

1. 19 августа 2026 г. в 21:47 UTCresolved

   Этот инцидент был урегулирован. Мы приносим извинения за срыв, который это вызвало. расследовать Мы расследуем проблему, когда пользователи в неамериканских регионах не могут устанавливать новые удаленные сессии. Пострадавшие пользователи получают сообщение «Engine unavailable» при запуске сеанса. Влияние ограничено клиентами в неамериканских регионах. Арендаторы, размещенные в регионе США, не пострадали. Мы предоставим обновление, как только у нас будет больше информации. Уведомление об обратном заполнении: этот инцидент был добавлен на нашу страницу статуса ретроспективно, чтобы обеспечить точную запись о влиянии сервиса. Более подробная информация об инцидентах с обратным заполнением доступна здесь.

2. 19 августа 2026 г. в 22:11 UTCpostmortem

   ##Обзор инцидентов Подгруппа клиентов в неамериканских регионах не смогла запустить новые сессии PRA и получила ошибку «Engine unavailable». Существующие рабочие сессии не пострадали. * Старт: 14 августа 2026, 09:46 UTC * Конец: 14 августа 2026, 10:45 UTC ##Коренная причина и восстановление Новая версия сервиса PRA была запущена в производство 14 августа 2026 года в 09:46 UTC. Новая версия некорректно применила требуемое значение конфигурации в производственной среде, что помешало сервису найти сессионный двигатель для неамериканских регионов. Пострадавшие клиенты не смогли запустить новые сессии и получили ошибку «Engine unavailable». После увеличения частоты ошибок бэкэнда во время мониторинга после развертывания, связанного с поступающими отчетами клиентов, развертывание было перенесено на предыдущую стабильную версию. Rollback завершился в 10:45 UTC. Разрешение было проверено с помощью бэкэнд-логов и путем подтверждения того, что затронутые клиенты могут успешно запускать новые сессии. ##Профилактические меры Проанализируйте процесс развертывания, чтобы определить, почему проблема конфигурации не была обнаружена до выпуска продукции. Внедрить поэтапную модель развертывания, чтобы новые версии услуг были выпущены в одном регионе и проверены перед более широким развертыванием. Ввести автоматизированные проверки здоровья после развертывания, включая запуск синтетического сеанса в каждом регионе, что продвижение ворот и вызвать откат от отказа. Мы искренне извиняемся за причиненный ущерб и ценим ваше терпение, пока мы работали над его устранением.

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

1. 3 августа 2026 г. в 04:55 UTCinvestigating

   Мы расследуем сообщения о ухудшении производительности, затрагивающих секретный сервер. Некоторые пользователи могут не иметь доступа к интерфейсу Vault. Пользователи могут столкнуться с ошибкой: [Federation Runtime]: удаленный EntryExports не определен, что может помешать доступу к секретам. Наша команда активно исследует причину и работает над восстановлением нормального сервиса. Мы будем предоставлять обновления по мере поступления дополнительной информации.

2. 3 августа 2026 г. в 14:31 UTCresolved

   После дальнейшего расследования мы определили, что эта проблема изолирована от локальных развертываний Secret Server и не влияет на Secret Server Cloud (SSC). Влияние на SSC не было выявлено в регионах США, ЕС или СЭО. Теперь этот инцидент урегулирован.

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

1. 29 июля 2026 г. в 04:12 UTCresolved

   Мы выявили проблему, затрагивающую Secret Server Cloud для подмножества клиентов в регионе Сингапура из-за повышенной нагрузки на бэкэнд-инфраструктуру. Пострадавшие пользователи испытывали медленное время отклика или трудности с доступом к своему экземпляру. Это был только вопрос производительности. Этот вопрос решен, нормальная работа восстановлена. Мы приносим извинения за любые неудобства, которые это могло вызвать. Уведомление об обратном заполнении: этот инцидент был добавлен на нашу страницу статуса ретроспективно, чтобы обеспечить точную запись о влиянии сервиса. Более подробная информация об инцидентах с обратным заполнением доступна здесь.

2. 20 августа 2026 г. в 11:49 UTCpostmortem

   ###Обзор событий 29 июля 2026 года подгруппа клиентов Secret Server Cloud в сингапурском регионе столкнулась с проблемой производительности из-за повышенной нагрузки на бэкэнд-инфраструктуру. Пострадавшие пользователи испытывали медленное время отклика или трудности с доступом к своему экземпляру. Начало работы: 29 июля, 1:41AM UTC End of Impact: 29 июля 2:32AM UTC ###Коренная причина В течение затронутого периода общий бэкэнд-ресурс, поддерживающий регион Сингапура, испытал всплеск использования, который подтолкнул его к максимальной мощности. Автоматизированный процесс, ответственный за масштабирование ресурсов для обработки увеличенной нагрузки, не был выполнен, как ожидалось, что привело к увеличению времени отклика для подмножества клиентов в этом регионе. ###Профилактические меры Для предотвращения рецидивов осуществляются следующие меры: • Улучшение процесса автоматизированного масштабирования для снижения риска возникновения подобных проблем в будущем. Мы искренне извиняемся за срыв, который это вызвало, и неудобства для ваших операций. Мы стремимся предотвратить повторение этих действий.

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

1. 28 июля 2026 г. в 14:03 UTCinvestigating

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

2. 28 июля 2026 г. в 14:15 UTCidentified

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

3. 28 июля 2026 г. в 16:34 UTCmonitoring

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

4. 28 июля 2026 г. в 23:07 UTCresolved

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

5. 15 сентября 2026 г. в 06:39 UTCpostmortem

   ##Обзор инцидентов 28 июля 2026 года небольшое подмножество арендаторов Secret Server Cloud не смогли войти в систему или столкнулись с ошибками при навигации между страницами. Пострадавшие арендаторы не смогли установить соединение со своей базой данных, из-за чего приложение не успело загрузиться. * Начало: 28 июля 2026, приблизительно 03:11 AM UTC * Конец: 28 июля 2026, приблизительно 04:05 вечера UTC Регионы, затронутые: Очень небольшое подмножество арендаторов в нескольких регионах ##Коренная причина и восстановление На этапе внутреннего релиза служба поддержки была перестроена и развернута в версии, которая не соответствовала версии, запущенной в производстве Secret Server Cloud. Две версии форматировали настройки подключения к базе данных по-разному, а более новый формат включал настройку, которую производственное приложение не распознавало. Эта ценность была записана во внутренний кэш и служила арендаторам, поскольку их кэшированные записи были обновлены. Поскольку сроки обновления варьируются в зависимости от арендатора, арендаторы пострадали в разные моменты, а не все сразу, поэтому влияние было ограничено подмножеством, а не полным регионом. Наша инженерная команда определила первопричину, перераспределила вспомогательную службу при производстве версии и очистила затронутые записи кэша. Доступ был восстановлен по мере распространения скорректированных значений, и каждый пострадавший арендатор был проверен индивидуально до закрытия инцидента. ##Профилактические меры Добавьте автоматизированное тестирование совместимости и проверки валидации развертывания, чтобы уловить несоответствия конфигурации и версии до того, как код достигнет производства. Улучшить обнаружение сбоев подключения к базе данных на уровне арендатора, чтобы этот класс проблем был идентифицирован с помощью внутреннего мониторинга, а не отчетов клиентов. Укрепление внутренних процессов обзора для управления кэшем и конфигурацией для снижения риска и воздействия аналогичных проблем в будущем. Мы искренне извиняемся за срыв, который это вызвало, и неудобства для ваших операций. Мы стремимся предотвратить повторение этих действий.

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

1. 27 июля 2026 г. в 18:05 UTCinvestigating

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

2. 27 июля 2026 г. в 19:34 UTCidentified

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

3. 27 июля 2026 г. в 20:10 UTCmonitoring

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

4. 27 июля 2026 г. в 21:30 UTCresolved

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

5. 4 августа 2026 г. в 20:24 UTCpostmortem

   ## Incident Overview On July 27, 2026, Secret Server Cloud \(US region\) customers experienced widespread failures with RDP sessions, remote password rotation, and folder creation. The root cause was a critical internal caching layer that filled up to capacity because session entries were being stored in it without expiration. As the cache filled, it began rejecting write operations, causing a backend processing service to fail. Messages continually accumulated in an internal message queue which degraded performance for all affected tenants. * Start: July 27, 2026, approximately 2:00 PM EDT * End: July 27, 2026, approximately 4:10 PM EDT * Region impacted: US ## Root Cause and Remediation The internal caching layer had been accumulating session data with no expiration for over 20 days. At the time of investigation, approximately 86% of cache entries had no expiration set. The root cause is a code-level bug that was not setting expirations properly on session entries. Once the cache reached capacity, new writes were rejected, breaking the log pipeline and cascading into broader service failures across tenants. To remediate, the caching layer was manually flushed at approximately 4:04 PM EDT, restoring write capacity and allowing the message queue to drain. A code fix to add TTL \(time-to-live\) to the affected keys has been identified and is in progress. ## Preventative Actions * Apply a code fix to add TTL to session entries and other unbounded growth keys in the caching layer, preventing recurrence regardless of deployment cadence. * Add memory utilization alerting for the caching layer at defined thresholds, so memory pressure is detected proactively before capacity is reached. * We are looking into adding a post-release action for flushing the cache as a standard step in the deployment process We sincerely apologize for the disruption this caused and the inconvenience to your operations. We are committed to preventing recurrence through the above actions.

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

1. 26 июля 2026 г. в 18:13 UTCresolved

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

2. 4 августа 2026 г. в 17:01 UTCpostmortem

   ## Incident Overview  On July 24, 2026, customers in the US region experienced Connector connectivity issues affecting authentication through the Delinea Platform. Some Connectors intermittently went offline while others in the same environment continued operating normally, with no consistent pattern distinguishing affected from unaffected Connectors. Restarting or re-registering an affected Connector did not restore connectivity.  * Start: July 24, 2026, approximately 4:50 PM ET \(8:50 PM UTC\)  * End: July 24, 2026, approximately 8:00 PM ET \(July 25, 12:00 AM UTC\)  ## Root Cause and Remediation  The root cause was overload on backend relay services that route Connector traffic to the Delinea Platform. Because impacted and unimpacted Connectors were sometimes present in the same customer environment, initial investigation focused on individual Connector configuration and network paths. Further investigation identified the issue on TCP relays in the US-West region; one affected relay was temporarily removed from the relay pool for isolation and diagnosis. This confirmed the underlying issue was load on the affected relays rather than a defect in the relay software or hardware itself.  To remediate, our team investigated and stabilized the affected relay services as they were identified, restoring Connector connectivity. Connectivity was confirmed restored the evening of July 24, and the incident was resolved by approximately 8:00 PM ET. No action was required from customers, and no customer data was lost.  ## Preventative Actions  * Added new relays in US-West and US-East to increase capacity and reduce the likelihood of relay overload recurring.  * Improve tooling for the backend relay services to make them more resilient and self-recovering under load.  * We are implementing additional monitoring of the relay services to detect this specific condition and connectivity degradation before customers are impacted.  We sincerely apologize for the disruption this caused and the inconvenience to your operations. We are committed to preventing recurrence through the above actions.

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

1. 24 июля 2026 г. в 16:24 UTCidentified

   Мы хотели предоставить вам обновленную информацию об инциденте, затрагивающем услугу (ы), перечисленные ниже. Наша команда усердно работает над решением этой проблемы, и мы добились значительного прогресса. Мы ценим ваше терпение и поддержку, поскольку мы работаем, чтобы полностью восстановить нормальное обслуживание. По любым вопросам или проблемам обращайтесь в нашу службу поддержки по адресу https://support.delinea.com.

2. 24 июля 2026 г. в 16:33 UTCidentified

   Мы определили причину периодических ошибок 504 / Gateway Timeout, которые некоторые клиенты испытывали при доступе к своим экземплярам платформы Delinea или при использовании операций на основе разъема. Проблема связана с повышенным временем отклика в бэкэнд-сервисе, который обрабатывает подключение разъема, что вызывает некоторые запросы на тайм-аут. Наша инженерная команда изолировала источник и активно применяет корректирующие действия для восстановления нормальной работы. Некоторые клиенты могут продолжать видеть периодические тайм-ауты, пока исправление не будет полностью установлено. Мы предоставим дополнительную информацию по мере изменения ситуации.

3. 24 июля 2026 г. в 22:34 UTCidentified

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

4. 24 июля 2026 г. в 23:48 UTCresolved

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

5. 4 августа 2026 г. в 16:40 UTCpostmortem

   ## Incident Overview  On July 24, 2026,  a subset of Delinea Platform customers in the US and AU regions experienced intermittent 504 Gateway Timeout errors, resulting in temporary service disruption while accessing Platform. On July 24, 2026, some Delinea Platform customers in US and AU regions experienced intermittent 504 Gateway Timeout errors, resulting in temporary service disruption while accessing the platform.  Start: July 24, 2026, 11:20 AM ET  End: July 24, 2026, 3:30 PM ET  ## Root Cause and Remediation  The incident was caused by an unexpected increase in request volume generated by a Secret Server Cloud synchronization process, which exceeded the processing capacity of The Platform service. As the service became overloaded, request latency increased and some requests exceeded the gateway timeout threshold, resulting in intermittent 504 Gateway Timeout errors for a subset of Platform customers.  Our engineering team applied immediate mitigations to reduce load while working to resolve the underlying capacity constraint, and is implementing a long-term solution to improve capacity handling and prevent similar incidents. Additional monitoring will also be added to detect and respond to this type of condition more quickly.  ## Preventative Actions  * Improve capacity handling: Enhance the backend capacity to better accommodate periods of elevated request volume without impacting customer traffic.  * Optimize Secret Server Cloud synchronization: Engineering has implemented mitigations to address the immediate issue and prevent recurrence in the short term. A long-term solution is being developed to further improve the handling of synchronization workloads.   * Expand monitoring and alerting: implement additional monitoring and alerting to detect elevated request volumes and performance degradation earlier, enabling faster response and mitigation.      We sincerely apologize for the disruption this caused and the inconvenience to your operations. We are committed to preventing recurrence through the above actions.

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

1. 21 июля 2026 г. в 21:55 UTCmonitoring

   Мы испытываем задержки в обработке аудиторских мероприятий для клиентов в нашем восточном регионе США. Ревизионные журналы и аудиторская деятельность могут оказаться запоздалыми или неполными в интерфейсах Delinea Platform и Secret Server Cloud. Никакие аудиторские мероприятия не теряются. Все события фиксируются и будут обрабатываться. Функциональность основных продуктов, включая секретный доступ, аутентификацию и управление паролями, не затрагивается. Наша инженерная команда определила первопричину и масштабировала базы данных и ресурсы обработки для устранения отставания. Отставание активно истощается.

2. 23 июля 2026 г. в 15:57 UTCresolved

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

3. 20 августа 2026 г. в 11:48 UTCpostmortem

   ###Обзор событий 20 июля 2026 года подгруппа клиентов Delinea Platform в регионе США столкнулась с задержками в обработке событий аудита, что привело к задержке между моментом совершения действий и моментом появления соответствующих событий аудита в журналах. * Начало: 20 июля 2026, 10:54 AM UTC * Конец: 23 июля 2026, 3:58 вечера UTC ### Коренная причина и восстановление Инцидент был вызван увеличением объема аудиторских мероприятий после недавнего выпуска Secret Server, который превысил пропускную способность конвейера аудиторских мероприятий в регионе США. По мере роста объема мероприятия были поставлены в очередь для обработки, а не доставлены в режиме реального времени, что привело к отставанию и соответствующей задержке в доступности журнала аудита. Во время этого инцидента не было потеряно ни одного события аудита. Наша инженерная команда масштабировала базовую мощность обработки данных для работы через отставание при мониторинге глубины очереди и скорости обработки. К 23 июля 2026 года все отложенные события были полностью обработаны, журналы аудита были текущими, и нормальные операции возобновились. ###Профилактические меры Улучшить автоматическое масштабирование на конвейере событий аудита, чтобы он мог поглощать увеличение объема без создания отставания или задержки доступности журнала. Улучшение мониторинга и оповещения об объеме обработки аудита и глубине очереди для выявления потенциальных задержек раньше и реагирования до воздействия на клиентов. Мы искренне извиняемся за срыв, который это вызвало, и неудобства для ваших операций. Мы стремимся предотвратить повторение этих действий.

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