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

1. 30 августа 2026 г. в 02:35 UTCinvestigating

   Уважаемый клиент, Примерно в 11:00 вечера (BRT) в пятницу, 29 августа 2026 года, мы определили нестабильность, влияющую на создание процесса в IDCloud. В течение этого периода некоторые запросы могут потерпеть неудачу или работать медленнее, чем обычно. Мы признаем неудобства, которые это может вызвать, и ценим ваше понимание. В ближайшее время будет представлено новое обновление. Команда Unico

2. 30 августа 2026 г. в 02:49 UTCidentified

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

3. 30 августа 2026 г. в 02:57 UTCmonitoring

   Уважаемый клиент, Наша инженерная команда провела корректирующие действия, необходимые для устранения нестабильности, влияющей на создание процессов в IDCloud. Окружающая среда вернулась к стабильности, а показатели доступности и времени отклика были восстановлены до нормального рабочего уровня по состоянию на 11:48 вечера. Сервис доступен для обычного использования. В настоящее время наша техническая команда находится под наблюдением, внимательно следит за окружающей средой, чтобы обеспечить постоянную производительность и действовать немедленно в случае любых колебаний. Мы ценим ваше понимание и подтверждаем, что в ближайшее время будут отправлены дальнейшие обновления. Команда Unico

4. 30 августа 2026 г. в 03:15 UTCresolved

   Уважаемый клиент, Исполнительное резюме и влияние Между 11:00 вечера и 11:48 вечера (BRT) 29 августа 2026 года сбой повлиял на создание процесса в IDCloud. Во время этого окна некоторые клиенты, использующие эти потоки, испытывали сбои и увеличение времени отклика, с распространением на зависимые поездки, включая аутентификацию, захват документов и доставку уведомлений. Не было никаких компромиссов в отношении целостности или безопасности обрабатываемой информации, и никакие данные не были потеряны. Показатели вернулись к нормальным операционным уровням в 11:48 вечера (BRT), причем нормализация подтвердилась как в нашем мониторинге, так и на стороне заказчика, охватывая создание и завершение процесса. Коренная причина и разрешение Происхождение было определено в нашем уровне данных: внутренняя процедура обслуживания застряла, и операции приложений начали стоять в очереди за ней, пока доступный предел подключения не был исчерпан, уменьшая производительность обработки. Наша инженерная команда хирургически прекратила только застрявшую рутину, немедленно выпустив очередь. Полностью восстановлены соединения и вычислительная мощность без изменений данных. Обязательство и следующие шаги Наша инженерная команда сосредоточится на трех направлениях: ограничение времени ожидания для внутренних процедур технического обслуживания, предотвращение одновременного выполнения процедур против одной и той же структуры и укрепление устойчивости обслуживания к колебаниям уровня данных. Подробное вскрытие, включая полный график и план действий со сроками, будет распространено в ближайшее время. Мы приносим искренние извинения за влияние на ваши операции и остаемся доступными через наши каналы поддержки. Команда Unico

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

1. 10 августа 2026 г. в 20:26 UTCidentified

   Уважаемый клиент, Мы обнаружили влияние на некоторые запросы IDCloud, влияя на возможности оповещения о поведении (IDTrust) и поток 1:N. Эта нестабильность может также затронуть клиентов в Мексике, которые используют эту возможность. Наша инженерная команда мобилизована для скорейшего решения вопроса. В ближайшее время мы предоставим новые обновления.

2. 10 августа 2026 г. в 20:29 UTCmonitoring

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

3. 10 августа 2026 г. в 21:01 UTCresolved

   Исполнительное резюме и влияние Около 5:08 вечера автоматическое оповещение обнаружило падение доступности службы распознавания лиц (1:N), вызвавшее инцидент. Проблема быстро обострилась и начала влиять на службу оповещения о поведении и, впоследствии, на поток создания процесса из-за каскадных тайм-аутов между этими службами. Влияние повлияло на подмножество клиентов, использующих эти возможности. Сообщается, что ситуация стабилизировалась в 5:22 вечера, а показатели вернулись к нормальному уровню. Коренная причина и разрешение Основной причиной был всплеск трафика, вызванный внутренней рабочей нагрузкой, которая отправляла большой объем запросов на распознавание лиц непосредственно в биометрический конвейер, минуя пограничный слой, используемый обычным клиентским трафиком. Этот дополнительный том насытил емкость базы данных, поддерживающей службу распознавания лиц. Насыщение вызвало тайм-ауты в этой службе, которые каскадировались к службе биометрической оркестровки двигателя, затем к службе оповещения о поведении и, наконец, к потоку создания процесса с использованием этих возможностей. Чтобы решить проблему, команда остановила рабочую нагрузку, ответственную за всплеск, и увеличила емкость пострадавшей базы данных. Эти действия смягчили проблему, при этом объем ошибок вернулся к почти нулевому уровню. Обязательство и следующие шаги В качестве превентивной меры против рецидивов был открыт пункт, касающийся последующих мер, с тем чтобы ввести ограничение по ставкам для вида внутренней рабочей нагрузки, вызвавшей скачок. Увеличение пропускной способности пострадавшей базы данных уже было осуществлено во время самого инцидента.

4. 25 августа 2026 г. в 13:05 UTCpostmortem

   ** Резюме** 10 августа 2026 года, между 5:08 вечера и 5:27 вечера (время Бразилии), показатель доступности для потока распознавания лиц 1:N упал ниже 95%, с общим воздействием примерно 19 минут. Инцидент был вызван насыщением базы векторного поиска, используемой биометрическим движком, в результате неожиданного поведения в механизме потребления очереди, который генерировал объем вызова в 2,36 раза выше сконфигурированного. Избыточная нагрузка достигла максимального предела масштабирования базы данных, вызывая каскадные тайм-ауты в нескольких зависимых сервисах и затрагивая 55 пользователей-клиентов с ошибками в течение периода. ** Воздействие** Пользователи распознавания лиц, аутентификации и создания процессов перетекают из нескольких клиентов, испытывающих ошибки и тайм-ауты в течение периода. Насыщение базы данных каскадируется через биометрическую оркестровку, движок и услуги по созданию процессов. Смягчение было осуществлено путем отключения внутренней службы и увеличения максимального предела масштабирования базы данных, стабилизируя службу в 5:27 вечера. **Корневая причина** Основной причиной было сочетание факторов, связанных с поведением служб и возможностями соответствующей инфраструктуры. Сервис был настроен с ограничением в 2 запроса в секунду, но механизм потребления очередей вел себя неожиданно: сообщения, обработка которых превысила крайний срок подтверждения, были переделаны очередью без отмены первоначального исполнения — превратив 938 рабочих пунктов в 2217 эффективных вызовов \(~8,4 RPS\). Этот усиленный трафик достигал базы данных, не проходя через пограничный защитный слой, что обычно ограничивало объем запроса, поскольку сетевой путь, используемый в этом потоке, не проходил через эти элементы управления. База данных, уже работающая близко к максимальному пределу масштабирования, не смогла поглотить дополнительную нагрузку — ее процессор достиг 88% при масштабировании до настроенного потолка в 100 узлов — и задержка запроса подскочила с ~3 секунд до ~18,75 секунды при p90, распространяя тайм-ауты по всей цепочке зависимых сервисов. ** Резолюция** Команда определила рассматриваемый процесс как источник нагрузки в течение нескольких минут после оповещения. Процесс был отключен, и максимальный предел масштабирования базы данных был увеличен со 100 до 150 узлов. С этими двумя действиями служба стабилизировалась в 5:27 вечера. *Уроки выучены* Инцидент показал, что ограничение скорости, применяемое только на стороне публикации сообщения, является недостаточным, когда потребитель может увеличить объем за счет перепродажи. Контроль за ставками и параллелизмом должен существовать и на стороне потребления. Кроме того, внутренние службы, которые получают доступ к критически важным компонентам через пути, которые обходят защиту краев, представляют структурный риск — любой внутренний клиент может генерировать неконтролируемую нагрузку на общую инфраструктуру.

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

1. 31 июля 2026 г. в 12:42 UTCinvestigating

   Презадо клиенты, Identificamos uma instabilidade técnica pontual que afeta a atualização do painel de acompanhamento após o envio de documentos. Reforçamos que o fluxo de envio e assinatura está funcionando normalmente: os destinatários continuam recebendo e conseguindo assinar os arquivos. Нет entanto, o registro do envio pode temporariamente não ser exibido na lista de acompanhamento do remetente. Nossa equipe de engenharia já está atuando para corrigir a exibição na interface e restabelecer o histórico no painel o mais breve possível. Pedimos desculpas pelo inconveniente e manteremos todos informados sobre o progresso. Atenciosamente,

2. 31 июля 2026 г. в 13:08 UTCidentified

   Презадо клиенты, Gostaríamos de atualizar o status sobre a visualização de documentos no painel de acompanhamento. O problema foi identificado com sucesso por nossa equipe técnica. No momento, os engenheiros já estão subindo a correção para restabelecer a exibição correta de todos os envios na interface do remetente. Lembramos que o processamento, envio e assinatura dos documentos continuam operando normalmente. Volataremos com uma nova atualização assim que a correção for concluída e entrarmos na fase de monitoramento. Atenciosamente,

3. 31 июля 2026 г. в 13:20 UTCmonitoring

   Презадо клиенты, Informamos que a correção para a exibição no painel de acompanhamento foi aplicada com sucesso. A lista de documentos e históricos de envios já está retornando à normalidade. No momento, nossa equipe de engenharia está monitorando o ambiente de perto para garantir a estabilidade total do serviço. Agradecemos a paciência e traremos a confirmação do encerramento em breve. Atenciosamente,

4. 31 июля 2026 г. в 14:06 UTCresolved

   Презадо клиенты, Informamos que o incidente relacionado à exibição de envios no painel de acompanhamento foi oficialmente encerrado. Após aplicação da correção e o período de monitoramento, confirmamos que a listagem e o histórico de documentos foram totalmente restabelecidos, e a plataforma opera em completa estabilidade. Agradecemos pela compreensão e paciência de todos durante o processo. Atenciosamente,

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

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

   Исполнительное резюме и влияние Мы хотели бы сообщить вам, что инцидент, временно затрагивающий службу уведомлений ID Cloud Webhook, был устранен. Период воздействия: с 08:32 до 10:05. Воздействие платформы: нестабильность была строго ограничена доставкой уведомлений в Webhook, что привело к задержке распространения сообщений. Не было деградации основной платформы, не было сбоев в движке liveness, не было потери данных. Влияние на клиента: проблема затронула небольшую часть клиентов. Клиенты, которые внедрили поток опросов GET в качестве непредвиденной ситуации, не испытывали простоев или операционного воздействия. Коренная причина и разрешение Коренная причина: нестабильность была вызвана обновлением функции в окружающей среде. Временное несоответствие в разрешениях доступа между очередью задач и маршрутом назначения вызвало отказ в запросах, что привело к временному отставанию уведомлений. Решительные действия: Техническая команда завершила перенаправление трафика в новую среду, восстановив надлежащую связь между компонентами и выпустив отставание Webhooks. Обработка вернулась к норме, и очередь отправки была полностью очищена. Обязательство и следующие шаги Стабильность наших услуг является нашим главным приоритетом. Для обеспечения полной прозрачности и предотвращения рецидивов наша инженерная команда сосредоточится на следующих направлениях: Подробное посмертное исследование: будет подготовлен всеобъемлющий доклад с подробным анализом первопричин и планом превентивных действий. Улучшения видимости: Мы будем корректировать показатели мониторинга, чтобы обеспечить большую видимость ошибок межсервисной связи во время переходных сценариев. Мы искренне извиняемся за неудобства и остаемся доступными для любых дальнейших разъяснений. Искренне, команда Unico

2. 7 августа 2026 г. в 13:08 UTCpostmortem

   ** Резюме** 29 июля 2026 года, между 8:32 и 10:05 утра (время Бразилиа), служба доставки веб-хуков была ухудшена примерно на 1 час и 33 минуты. Инцидент был вызван запланированной миграцией инфраструктуры, которая создала переходное состояние несовместимости: после того, как внутренние маршруты были переведены в новый кластер, служба веб-хуков начала генерировать токены аутентификации из нового кластера, но поставки все еще направлялись в старый кластер, который отклонил токены с ошибкой авторизации. Утерянные события были переработаны по требованию. ** Воздействие** Одновременно пострадали несколько продуктов, включая аутентификацию, платежи и потоки на борту. Пользователи клиентов, которые полагались исключительно на уведомления Webhook для продолжения своих бизнес-потоков, испытывали операционные перебои в течение периода. Клиенты, которые внедрили активный опрос в качестве резервного механизма, испытали снижение воздействия. **Корневая причина** Коренная причина была выявлена при планировании миграции: процедура не отображала цепную зависимость потока веб-хуков, где внутренний маршрут создает асинхронную задачу, которая, в свою очередь, вызывает общественный маршрут доставки. Путем миграции внутренних маршрутов и общественных маршрутов отдельными шагами было создано окно несовместимости, в котором токены, генерируемые новым кластером, были отклонены политикой авторизации старого кластера, которая специально подтвердила предыдущий идентификатор учетной записи службы. Этот сценарий не был выявлен в ходе оценки риска изменения, и ни один из существующих показателей качества обслуживания не охватывал асинхронный уровень доставки, где произошел сбой. ** Резолюция** Команда определила несовместимость токенов как источник сбоев и завершила миграцию общественных маршрутов в новый кластер, устранив расхождение. С этого момента ожидающие поставки в очереди начали нормально обрабатываться. Воздействие прекратилось в 10:05 утра, а движение по старому кластеру достигло нуля в 10:32 утра. *Уроки выучены* Инцидент показал, что миграции, связанные с цепными асинхронными потоками доставки, требуют скоординированной миграции всех маршрутов, участвующих в цепочке - внутренних и общественных - без окон несовместимости между кластерами. Используемый постепенный подход, хотя и подходит для большинства миграций, создал здесь длительный период отказа, которого можно было бы избежать при атомном переходе или гораздо более коротком переходном окне. Кроме того, отсутствие наблюдаемости на асинхронном слое доставки было причиной того, что инцидент не был обнаружен внутренне — существующие показатели измеряли только принятие события, а не фактическую доставку. Создание специальных предупреждений о сбоях и отставании на этом уровне является наиболее актуальным улучшением мониторинга.

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

1. 24 июля 2026 г. в 21:47 UTCinvestigating

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

2. 24 июля 2026 г. в 21:53 UTCmonitoring

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

3. 24 июля 2026 г. в 22:18 UTCresolved

   Исполнительное резюме и влияние Начиная с 6:05 вечера (время Бразилиа), в сервисе Webhook произошла нестабильность, что привело к сбою в обработке событий и доставке уведомлений для пострадавших операций в течение этого периода. Коренная причина и разрешение Инцидент был вызван проблемой с общей учетной записью службы, используемой во многих службах, что привело к сбоям аутентификации. После выявления первопричины инженерная команда восстановила необходимые учетные данные и конфигурацию. Нормальная работа была полностью восстановлена в 6:29 вечера (BRT). Обязательство и следующие шаги В рамках непрерывного совершенствования и снижения рисков команда инженеров проведет обзор зависимостей ресурсов и управления доступом к различным услугам. Это позволит избежать подобных проблем с конфигурацией в будущих корректировках инфраструктуры.

4. 3 августа 2026 г. в 20:00 UTCpostmortem

   ** Резюме** 24 июля 2026 года, между 6:05 вечера и 6:29 вечера (время Бразилии), служба создания и доставки веб-хука была недоступна в течение примерно 24 минут. Инцидент был вызван потерей доступа к учетной записи службы инфраструктуры во время процесса вывода из эксплуатации ресурсов, связанного с миграцией кластеров, проведенной несколькими днями ранее. Затронутая учетная запись была разделена несколькими службами без документирования этой зависимости, в результате чего служба веб-хук потеряла свою способность аутентификации и перестала создавать и доставлять события. ** Воздействие** В течение этого периода было прервано создание и доставка событий Webhook, что затронуло 18 пользователей с более чем 1550 зарегистрированными ошибками. Воздействие каскадировалось на другие сервисы, которые зависели от одного и того же потока аутентификации, вызывая одновременную деградацию различных возможностей платформы. **Корневая причина** Корневая причина была выявлена в конфигурации зависимостей сервиса. Эта межсервисная зависимость не была ни документирована, ни видна на карте зависимости. Когда процесс вывода из эксплуатации удалил учетную запись в рамках очистки ресурсов первоначальной службы, не было автоматизированной проверки, чтобы проверить, используется ли учетная запись другими активными службами. Отсутствие этой гарантии скрывало зависимость до тех пор, пока ее удаление не привело к широко распространенным сбоям в аутентификации. ** Резолюция** Команда быстро определила нестабильную учетную запись службы как источник сбоев аутентификации. Учетная запись была вручную скорректирована и применена к кластеру, восстановив сервис в 6:29 вечера. Общая продолжительность удара составила около 24 минут. *Уроки выучены* Инцидент выявил риски устаревших конфигураций, которые создают скрытые зависимости между службами: одного изменения ресурса во время планового обслуживания было достаточно, чтобы нарушить работу нескольких служб одновременно. Процесс вывода из эксплуатации инфраструктурных ресурсов должен включать автоматическую проверку зависимости перед любым изменением.

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

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

   Уважаемый клиент, Мы изучаем нестабильность функций IDCloud, которая влияет на потоки аутентификации в процессе путешествия, в частности, на Web Journey (ранее ByUnico). Наша инженерная команда мобилизована для скорейшего решения вопроса. В ближайшее время мы предоставим дополнительные обновления.

2. 21 июля 2026 г. в 16:49 UTCmonitoring

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

3. 21 июля 2026 г. в 18:02 UTCresolved

   Исполнительное резюме и влияние Начиная примерно с 12:44 вечера (время Бразилиа) 21 июля 2026 года, часть пользователей в уменьшенном путешествии на борту испытывала более медленную загрузку начальных экранов в потоке. Воздействие наблюдалось во всех средах, где используется это путешествие, влияя на воспринимаемую скорость и, в меньшей степени, способность пользователей завершить процесс в течение этого периода. Коренная причина и разрешение Расследование продолжается, чтобы подтвердить окончательную причину инцидента. Не было никакого влияния на серверы, сеть или инфраструктуру — было подтверждено, что проблема была изолирована от экрана на устройстве пользователя. В качестве меры сдерживания ответственная группа применила превентивную корректировку в 1:39 вечера (BRT), и время загрузки вернулось к норме в течение нескольких минут. Анализ для проверки и подтверждения первопричины все еще проводится технической группой. Обязательство и следующие шаги В рамках непрерывного совершенствования процессов реагирования на инциденты команда обязуется усилить автоматический поток эскалации для ответственных команд, делая активацию еще более прямой и эффективной с момента открытия инцидента. Кроме того, мониторинг скорости загрузки будет усилен во время развертывания новых изменений в этом путешествии с целью выявления и коррекции потенциальных регрессий еще быстрее, сводя к минимуму воздействие на пользователей в подобных ситуациях в будущем.

4. 3 августа 2026 г. в 14:01 UTCpostmortem

   ** Резюме** 21 июля 2026 года, между 12:44 PM и 1:43 PM \(время Бразилии \), показатели производительности загрузки страницы для уменьшенного путешествия сильно ухудшились, при этом среднее время загрузки подскочило с ~4,8 до ~8,9, а p95 достиг 31,5 секунды. Инцидент был вызван ограничением скорости, применяемым облачной инфраструктурой для соединений, исходящих от провайдера, что предотвратило загрузку интерфейсных активов. ** Воздействие** Пользователи из 32 клиентов испытывали чрезвычайно медленную загрузку страниц или сбои при полной загрузке, при этом было зарегистрировано около 94 ошибок в пути. Ошибки «Initialization Timeout» — срабатывающие, когда приложение не монтируется в течение 30 секунд — достигли около 23 тысяч случаев за этот период. **Корневая причина** Коренная причина была выявлена в сетевом уровне инфраструктуры: провайдер CDN консолидирует трафик через ограниченный набор исходящих IP-адресов. Всплеск новых TCP-соединений и рукопожатий TLS, происходящих от этих IP-адресов, вызвал автоматические механизмы защиты сетевого уровня облачной инфраструктуры, которые начали ограничивать скорость соединений еще до обработки HTTP. Поскольку эти сбои происходили на сетевом уровне — до обработки HTTP — они не появлялись в стандартных журналах запросов, что делало проблему невидимой для обычного мониторинга и значительно усложняло диагностику. ** Резолюция** Воздействие прекратилось с естественным восстановлением скорости, применяемой облачной инфраструктурой. Деактивация компонента, первоначально отмеченная как возможная причина, временно совпала с восстановлением, но позже было подтверждено, что она не связана с инцидентом. Исправления конфигурации - включение HTTP Keep-Alive с расширенным тайм-аутом и добавление правила разрешения для IP-адресов CDN на уровне защиты края - были определены в качестве последующих элементов группами поддержки вовлеченных поставщиков. *Уроки выучены* Инцидент показал, что сбои на сетевом уровне между CDN и облачной инфраструктурой невидимы для стандартного мониторинга приложений. В качестве последующих элементов команда определила необходимость внедрения исправлений конфигурации, рекомендованных поставщиками, и расширения наблюдаемости на уровне доставки активов для проактивного обнаружения этого типа деградации.

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

1. 21 июля 2026 г. в 14:39 UTCidentified

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

2. 21 июля 2026 г. в 14:46 UTCidentified

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

3. 21 июля 2026 г. в 14:50 UTCmonitoring

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

4. 21 июля 2026 г. в 16:00 UTCresolved

   Исполнительное резюме и влияние 21 июля 2026 года, примерно в 11:17 утра по Гринвичу, в потоках создания и запроса IDCloud было обнаружено снижение доступности. Во время окна удара часть клиентов испытывала повышенную задержку и сбои (тайм-ауты) в этих операциях, которые распространялись по цепочке зависимых услуг. Эффективное воздействие концентрировалось в окне продолжительностью около 23 минут. На пике показатели погрешности и задержки были выше нормального операционного уровня. Коренная причина и разрешение Расследование указало на деградацию базы данных считывания (репликации), поддерживающей эти возможности в качестве источника. Эта база данных начала показывать увеличенную нагрузку и время выполнения запроса, с внутренним утверждением, которое застопорило обработку и резервное копирование запросов на чтение. В результате вышеперечисленные службы начали накапливать тайм-ауты и запускать механизмы защиты (выключатели), создавая каскадный эффект, испытываемый клиентами. Обязательство и следующие шаги Unico рассматривает этот инцидент с подробным посмертным заключением, которое уже разрабатывается, и проведет совещание после инцидента для консолидации превентивных действий. К числу последующих мер, уже принятых в ходе ответов, относятся подготовка диагностических процедур и запросов для ускорения выявления разногласий на этом уровне базы данных и повышения наблюдаемости за соответствующими базами данных. Подробные профилактические действия будут распространены в посмертном периоде. Мы подтверждаем нашу приверженность стабильности и надежности платформы и приносим извинения за неудобства, причиненные в период нестабильности. Команда Unico.

5. 28 июля 2026 г. в 12:10 UTCpostmortem

   ** Резюме** 21 июля 2026 года, между 11:41 и 11:43 (время Бразилиа), поток создания процесса стал недоступен, при этом основная частота ошибок сервиса достигла 42%, а задержка p99 составила 15,75 секунды. Инцидент был вызван насыщением биометрической базы данных репликой чтения: пул памяти базы данных больше не мог обслуживать наиболее часто используемый набор данных, что приводило к тому, что обычно быстрые запросы возвращались к считыванию диска, создавая самоусиливающуюся спираль накопленных сеансов и увеличивая задержку. ** Воздействие** Пользователи процесса создания, аутентификации и платежей через несколько клиентов получили ошибки и тайм-ауты в течение периода. Основная база данных оставалась нетронутой на протяжении всего инцидента — сбой был выделен в прочитанную копию. **Корневая причина** Основной причиной было насыщение: запросы, используемые в потоке аутентификации, выполняли обширное сканирование на критических таблицах из-за отсутствия индексов. В нормальных условиях такое поведение переносилось инфраструктурой баз данных. Когда объем памяти достиг своего предела и больше не мог хранить наиболее доступные данные в кэше, каждое считывание начинало извлекать данные с диска, что делало стоимость каждого запроса экспоненциально выше. Этот резкий эффект коллапса, когда постепенная деградация уступает место широко распространенной неудаче, стал самоусиливающимся по мере накопления сессий в ожидании ответов и увеличения внутреннего спора о ресурсах базы данных. Кроме того, весь трафик считывания для критического потока был сосредоточен на одной реплике, без распределения или альтернативного маршрута, что устраняло любую устойчивость к этому типу деградации. ** Резолюция** База данных восстанавливалась естественным образом по мере истощения накопленных сеансов, не требуя ручного вмешательства. Команда переросла в команду базы данных и контролировала стабилизацию обслуживания. Инцидент был закрыт после подтверждения того, что нормальная операция была восстановлена. *Уроки выучены* Инцидент выявил структурные пробелы в уровне базы данных: отсутствие индексов по критическим запросам и концентрация всего считываемого трафика на одной реплике без альтернативного маршрута. В качестве последующих действий команда уделила первоочередное внимание созданию недостающих индексов, распределению трафика чтения по репликам и созданию диагностических журналов для ускорения реагирования на будущие инциденты аналогичного характера.

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

1. 20 июля 2026 г. в 12:33 UTCidentified

   Уважаемый клиент, Мы выявили нестабильность в некоторых из наших возможностей IDCloud, влияющих на GetSelfie, создание процессов и потоки деталей процессов для Web Journey (ранее ByUnico). Потоки API Journey (ByClient) не пострадали. Наша инженерная команда мобилизована для скорейшего решения вопроса. В ближайшее время мы будем следить за дальнейшими обновлениями.

2. 20 июля 2026 г. в 12:35 UTCidentified

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

3. 20 июля 2026 г. в 12:39 UTCmonitoring

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

4. 20 июля 2026 г. в 13:22 UTCresolved

   Исполнительное резюме и влияние Мы определили нестабильность, влияющую на процессы захвата и визуализации, а также аутентификации для веб-путешествия, с воздействием между 09:07 и 09:21 (BRT). Влияние достигло части клиентов, использующих этот поток; API Journey не был затронут. Коренная причина и разрешение Корневая причина связана с изменением конфигурации, применяемым в производстве, что вызвало повышенную нагрузку на внутренний компонент базы данных. Эта повышенная нагрузка повысила задержку и ошибки в интеграционном слое, что, в свою очередь, вызвало защитный механизм и временно прервало потоки Web Journey. Инженерная команда отменила изменение конфигурации, чтобы смягчить проблему, и ситуация нормализовалась вскоре после этого. Обязательство и следующие шаги Инженерная команда продолжает следить за окружающей средой после отката внесенных изменений. Подробное вскрытие будет передано нашей команде в ближайшие дни. Приносим извинения за неудобства. Команда Unico!

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

   **Summary** On July 20, 2026, between 9:07 AM and 9:21 AM \(Brasília time\), the selfie capture and authentication flows were unavailable for approximately 14 minutes. The incident was caused by a query without an adequate index running as part of the database migration flow, causing database CPU to spike to 53%, dependent service latency to jump 78 times above normal, and the circuit breaker mechanism to fully block calls to the affected service. The causing behavior was reverted and the service recovered in approximately 1 minute. **Impact** Users of the selfie, authentication, and web-based proof-of-life flows received open-circuit errors during the period, with 743 and 125 requests blocked respectively in the most affected flows. The service returned to normal at 9:21 AM after the causing behavior was reverted **Root Cause** The root cause was identified in the database migration flow: a query introduced as part of the migration lacked the index needed to run efficiently on the new database. When the new behavior was activated in production, the query began performing full scans per tenant, with the number of rows read jumping from ~5 million to ~25 million per execution, saturating the database CPU and causing response latencies of up to 10 seconds. **Resolution** The team identified the database CPU spike as the source of the problem and correlated it with the recently introduced behavior change approximately 7 minutes after the first alert. The change was reverted at 9:20 AM, and the service recovered immediately. **Lessons Learned** The incident showed that volume differences between validation and production environments can mask performance issues that only manifest at real-world scale. Silent error handling in the application worsened the situation by making the degradation invisible to monitoring. As follow-up actions, the team prioritized creating the missing index and removing the silent error suppression pattern.

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

1. 16 июля 2026 г. в 14:02 UTCinvestigating

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

2. 16 июля 2026 г. в 14:08 UTCmonitoring

   Уважаемый клиент, Наша команда определила проблему и приняла меры для разрешения инцидента. Мы столкнулись с нестабильностью в нашей системе аутентификации для порталов Unico People, а также проблемами в нашей службе обмена сообщениями, влияющими на клиентов в потоке IDCloud, для доставки SMS и электронной почты. Наша инженерная команда остается мобилизованной, контролируя окружающую среду, чтобы обеспечить ее надлежащее функционирование.

3. 16 июля 2026 г. в 15:28 UTCresolved

   Исполнительное резюме и влияние В 10:51 утра 16/07/2026 в службе аутентификации на портале приема Unico People и в мессенджерах была выявлена проблема, которая повлияла на доставку SMS и почтовых ссылок на клиентов Unico People и IDCloud, а также аутентификацию клиентов B2C на портале приема Unico People. Воздействие было ограничено этими двумя потоками и не повлияло на основной критический путь продукта. Инцидент продолжался около 30 минут до полного разрешения. Коренная причина и разрешение Первопричина была идентифицирована как давление на один узел кластера обмена сообщениями, которое достигло критического порога диска, ухудшая обработку очередей, ответственных за доставку сообщений и аутентификацию. Инженерная группа увеличила емкость хранилища кластера примерно в 10:59 утра, что позволило в считанные минуты нормализовать очереди и показатели мониторинга. Окружающая среда контролировалась до полного восстановления, и инцидент был закрыт в 11:20 утра. Обязательство и следующие шаги Инженерная группа рассмотрит критерии эскалации тревоги и определения приоритетов для этого типа деградации, поскольку оповещения правильно определили проблему, но автоматический поток эскалации в ответственную команду может быть улучшен. В настоящее время готовится подробное посмертное заключение, которое будет распространено в ближайшие дни.

4. 3 августа 2026 г. в 12:14 UTCpostmortem

   ** Резюме** 16 июля 2026 года, между 10:12 и 11:10 утра, служба обмена сообщениями и аутентификации была деградирована примерно на 58 минут. Причиной стало насыщение диска на одном из узлов кластера очередей сообщений, который, достигнув настроенного лимита, автоматически блокировал всех издателей, вызвав отставание до 33 тысяч сообщений в очереди. Это повлияло на доставку ссылок для аутентификации через SMS и электронную почту, а также на поток аутентификации конечного пользователя на портале приема Unico People. ** Воздействие** Пользователи, ожидающие ссылки на аутентификацию через SMS или электронную почту, не получали их в течение периода. Конечные пользователи продукта управления людьми, пытающиеся аутентифицироваться на портале приема, также не смогли получить доступ к сервису. Удар был сдержан после расширения диска кластера. **Корневая причина** Коренная причина была выявлена в потоке обработки сообщений: чрезмерно большие полезные нагрузки, генерируемые компонентом аудита, который включал ненужные данные, превысили предел размера, принятый кластером очередей сообщений. Поскольку они были детерминистски отвергнуты при каждой попытке, эти сообщения направлялись в тупиковые очереди после исчерпания всех повторов. У этих очередей не было политики истечения срока действия или автоматической очистки, в результате чего сообщения накапливались бесконечно и постепенно потребляли дисковое пространство кластера. ** Резолюция** Диск кластера был расширен до 500 ГБ на узел, что сразу нормализовало очереди и метрики кластера. Служба вернулась в норму в 11:10 утра. Структурная первопричина — неопределенное накопление в очередях «мертвой буквы» — остается в качестве последующего пункта, который необходимо рассмотреть. *Уроки выучены* Инцидент подтверждает, что устранение только симптома (насыщение диска) без исследования первопричины накопления гарантирует рецидив проблемы. Отсутствие политики жизненного цикла для очередей с мертвой буквой и отсутствие проверки размера полезной нагрузки до публикации являются двумя центральными структурными пробелами, которые необходимо исправить. Кроме того, оповещение, которое помечало проблему, было классифицировано как низкоприоритетное, что вызвало задержку примерно на 38 минут между срабатыванием оповещения и формальным открытием инцидента — неприемлемый интервал для критического ухудшения обслуживания.

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

1. 13 июля 2026 г. в 12:51 UTCidentified

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

2. 13 июля 2026 г. в 13:06 UTCmonitoring

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

3. 13 июля 2026 г. в 13:47 UTCresolved

   Исполнительное резюме и влияние 13 июля 2026 года мы выявили нестабильность в нашей способности проверки личности, генерируя ошибки на минимальной части запросов IDCloud, влияя на несколько потоков аутентификации. Проблема была обнаружена с помощью автоматических оповещений о доступности около 9:27 утра BRT, с небольшим увеличением ошибок, уже заметных примерно с 8:00 утра BRT и значительным ухудшением, начиная примерно с 9:07 утра BRT, достигая пикового воздействия около 9:49 утра BRT. Коренная причина и разрешение Коренная причина была идентифицирована как постепенное изменение, применяемое к компоненту внутренней аутентификации, что вызвало сбой в проверке подписи токена сеанса. Как только первопричина была подтверждена, инженерная команда вернула изменения, и доступность услуг вернулась к норме. Самая критическая фаза удара длилась около 44 минут. Обязательство и следующие шаги Инженерия оценивает улучшения в процессе проверки изменений для постепенного развертывания, затрагивающего критические компоненты аутентификации, включая автоматические механизмы отката в случае скачков ошибок во время этого типа развертывания. Ожидается, что подробное посмертное вскрытие будет распространено внутри страны в качестве следующего шага.

4. 20 июля 2026 г. в 22:47 UTCpostmortem

   Оригинальное название: Authentication Flow Instability ** Дата инцидента: ** 13 июля 2026 года ** Длительность воздействия: ** ~44 минуты ##Резюме 13 июля 2026 года мы выявили ухудшение доступности в потоках аутентификации платформы. Инцидент был вызван несовместимостью, введенной во время развертывания внутреннего компонента, ответственного за проверку токенов безопасности. Причина была диагностирована нашими операционными командами, и обновление восстановило стабильность системы в течение нескольких минут. # # Влияние Деградация длилась около 44 минут и одновременно повлияла на несколько потоков аутентификации на платформе, в результате чего частота ошибок составила около 0,9% в сервисах, ориентированных на клиентов. В течение этого периода некоторые конечные пользователи испытывали нестабильность и видели общие сообщения об ошибках при попытке аутентификации. Хотя событие длилось 44 минуты, оно колебалось между повышенной задержкой и недоступностью. ##Коренная причина Неисправность была вызвана дефектом программного обеспечения, введенным в обновление компонента проверки токенов безопасности, что привело к несовместимости между экземплярами, работающими в разных версиях. Эта несовместимость не была обнаружена в тестовых средах, поскольку требовала одновременного, параллельного исполнения разных версий. Кроме того, внутренняя конечная точка возвращала HTTP-ответ, даже когда проверка не удалась, что мешало автоматическим системам мониторинга развертывания обнаруживать проблему и автоматически останавливать развертывание. ## Резолюция Как только причина была идентифицирована, команда по вызову выполнила откат пострадавшего компонента, немедленно восстановив доступность потоков аутентификации. Инцидент был обнаружен автоматическими предупреждениями SLO в течение нескольких минут после начала деградации, и эскалация позволила полностью диагностировать и смягчить инцидент. ##Уроки, извлеченные Мы улучшим валидацию совместимости версий при развертывании, отрегулируем поведение HTTP-ответов внутренних конечных точек для запуска автоматического отката неудачных развертываний и стандартизируем обработку ошибок для предотвращения маскировки сбоев до достижения клиента. ##Приверженность постоянному совершенствованию Подобные инциденты укрепляют нашу приверженность постоянному повышению надежности платформы. Мы рассматриваем каждый инцидент как возможность обучения, пересмотра наших процессов, укрепления механизмов обнаружения и предотвращения и постоянного инвестирования в более надежные инженерные практики. Наша цель - продолжать повышать планку доступности и прозрачности для всех наших клиентов. Команда Unico.

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

1. 10 июля 2026 г. в 16:43 UTCinvestigating

   We are currently experiencing instability in IDCLOUD capabilities. Our technical team is already investigating the root cause. We will provide updates as soon as more information becomes available.

2. 10 июля 2026 г. в 17:12 UTCidentified

   We have identified an instability that may cause temporary downtime or latency in some of our core verification and risk analysis APIs. Affected Services: - Identity & Validation: Identity Verification, 1:1 Validation, Serpro Similarity Return - Risk & Fraud: Risk Score, Fraud Risk Classification - Documentation & Liveness: Document Reuse & Capture, Liveness Current Status & Next Steps: Our Engineering team is already fully engaged and investigating the root cause. We are working actively to isolate the behavior and restore normal operations as quickly as possible.

3. 10 июля 2026 г. в 17:25 UTCmonitoring

   Current Status & Next Steps Mitigation actions have been successfully applied, and the system is now stable. At this time, our Engineering team remains actively monitoring the platform's performance to ensure continued stability and normal operations. Thank you for your patience and understanding during this incident. Your services should now be operating normally.

4. 10 июля 2026 г. в 17:57 UTCresolved

   Executive Summary and Impact Between 1:21 PM and 2:16 PM (Brasília Time) on July 10, 2026, we identified a fluctuation in the availability of the process creation flow and related journeys, resulting in a temporary spike in the error rate of some of our main APIs. - Scope of Impact: The event exclusively affected the availability of certain journeys during this interval. Customers who did not experience an increase in their error rate during this period were not impacted. - Data Integrity: There was no compromise to the integrity or security of the processed information. - Mitigation: An initial workaround was applied within a few minutes, halting the volume of errors. The service was fully normalized at 2:16 PM, following stability confirmation from our Engineering and Monitoring teams. Root Cause The incident was triggered by instability in an infrastructure service, followed by a sudden degradation in the initialization of related internal components. Commitment and Next Steps We are deeply committed to the resilience of our platform. The corrective and preventive actions initiated during the incident are already being monitored to mitigate the risk of future occurrences of this nature. - Postmortem: A detailed technical report (Postmortem) will be shared soon, containing the complete timeline, architectural analysis, and a long-term action plan with defined deadlines. We sincerely apologize for the impact and instability caused. Our customers' trust is our highest priority, and we continue to work continuously to ensure the excellence of our services. Sincerely, Unico Team

5. 14 июля 2026 г. в 14:08 UTCpostmortem

   **Summary** On July 10, 2026, between 1:21 PM and 2:09 PM \(Brasília time\), the error rate in the process creation flow peaked at approximately 11% for about 9 minutes, with continued availability degradation until 2:09 PM. The incident was caused by an instability in the infrastructure configuration management component, which prevented the biometrics service pods from initializing correctly. The impact was amplified by a pre-existing memory consumption behavior \(which increased the frequency of pod restarts\) and by a traffic spike that triggered the creation of new instances — all of which were unable to initialize during the configuration component's instability window. ‌ **Impact** Multiple flows were affected simultaneously — including process creation, authentication, biometrics, payments, and internal operations — with errors propagating across all services dependent on the biometrics engine. At its peak, the error rate reached 11%. The number of available biometrics service pods dropped to near zero in both production clusters during the most critical window of the incident. ‌ **Root Cause** The root cause was related to an optimization opportunity in the biometrics service's startup logic: the application refused to come up if the infrastructure configuration management component returned a failure during boot, even when cached data was available for use as a fallback. This logic treated a transient communication outage the same way as a permanent configuration error, rendering the fallback cache unusable at exactly the moment it was needed most. When the configuration component became unstable, every pod attempting to restart — whether due to memory pressure or autoscaling — got stuck in a failure loop, unable to complete the initialization process. ‌ **Resolution** The team contained the initial impact by isolating traffic from one of the affected components, which stopped the error spike within approximately 9 minutes. Stabilization of the configuration management component followed, allowing pods to come back up normally. An emergency fix was prepared and deployed the same day, removing the restrictive validation that blocked startup — ensuring the fallback cache is used transparently in similar situations going forward. **Lessons Learned** The incident revealed that the service's resilience mechanism — the fallback cache — existed in the architecture but was neutralized by the startup logic, which prioritized strict data validation over environment availability. Startup paths for critical services must be designed to degrade gracefully when supporting infrastructure components are unstable, ensuring operational continuity. **Commitment to Stability and Continuous Improvement** We will continue to invest heavily in the robustness of our infrastructure to ensure our services consistently operate at the highest levels of efficiency, security, and reliability. Unico Team.

1. 7 июля 2026 г. в 21:22 UTCidentified

   Prezado Cliente, Identificamos uma latência seguida de indisponibilidade na criação de processos de algumas capacidades da Unico. Devido a isso, uma parcela de nossos clientes pode perceber lentidão ou aumento de erros em operações que envolvem o ID Score, ID Unico (Verificação de Identidade), ID Trust (Alerta de Comportamento) e ID Live (Prova de Vida). Nossa equipe de engenharia já foi acionada e está trabalhando no diagnóstico da causa raiz para normalizar o serviço o quanto antes. No momento, o time técnico realiza análises detalhadas em nossa camada de dados para mitigar os impactos. Comprometemo-nos a enviar novas atualizações em breve assim que tivermos novidades. Equipe Unico.

2. 7 июля 2026 г. в 21:32 UTCmonitoring

   Prezado Cliente, Informamos que nossa equipe de tecnologia identificou e solucionou a instabilidade que afetou o tempo de resposta das requisições para retorno das capacidades de ID Score, ID Unico (Verificação de Identidade), ID Trust (Alerta de Comportamento) e ID Live (Prova de Vida). Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

3. 7 июля 2026 г. в 22:14 UTCresolved

   Prezado Cliente, Incidente resolvido. Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

4. 13 июля 2026 г. в 21:18 UTCpostmortem

   **Post-Mortem: Availability Instability in Identity Processing** **Summary** On two occasions on consecutive days in July 2026, the identity processing service experienced brief drops in availability. These were caused by saturation in a shared database that supports part of the verification flow. Both events were quickly identified by the monitoring teams, mitigated within approximately 30 minutes, and resolved with zero data loss. **Impact** Incident 1 — July 6, 2026, from 13:00 to 13:34 \(BRT\): A sudden and legitimate spike in request volume overloaded the database replica serving the service. Clients using services dependent on verification score generation experienced slowness, as requests were automatically retried instead of returning errors. Verification processes continued to complete successfully, albeit with delays. Incident 2 — July 7, 2026, from 17:52 to 18:05 \(BRT\): A database query lacking a row-return limit was triggered by an edge-case data pattern, saturating the CPU of the same database replica. This increased latency and, for a short window \(around 13 minutes\), caused errors in certain steps of the verification flow for a subset of clients. In both cases, the impact was limited to the windows described above, without total service downtime and with zero data loss. **Root Cause** Both incidents share the same underlying cause: CPU saturation on a relational database replica that serves multiple capabilities of the identity verification service. In the first incident, a specific request volume surged roughly 10x within a few minutes, exceeding the provisioned capacity for the replica. The database infrastructure was not scaled to sustain the peak, leading to processing exhaustion \(CPU scheduling contention\) and a subsequent cascade of timeouts in dependent services. In the second incident, a specific query lacked a limit on returned rows. When executed for a record with an unusual volume of associated images, the query triggered a full table scan and sort, consuming all available processing power on the replica. This effect was amplified by two internal mechanisms that, combined, tripled the number of queries generated per request. **Resolution** In both incidents, the operations teams: Vertically scaled a secondary database replica and redirected traffic to it via a DNS update; Temporarily disabled mechanisms that were generating additional database load; Monitored the stabilization of availability metrics before declaring the incident resolved; Following the second incident, applied a definitive fix to the problematic query \(enforcing a limit on returned records\) and initiated a data-cleansing process for non-standard records that could replicate the scenario. **Lessons Learned** These incidents reinforced the need for defensive and systematic infrastructure design, applying explicit limits and pagination on database queries to eliminate latent risks under atypical traffic. It became evident that component migrations can inadvertently strip away implicit protections against overload. This makes the implementation of declarative resilience mechanisms—such as proper timeouts, circuit breakers, and connection limits—indispensable. Additionally, the scenario highlighted the importance of investigating the root cause of recurring saturation patterns rather than relying solely on point-in-time mitigations, as well as the urgency of monitoring and refactoring architectures that multiply database calls per request to mitigate load amplification risks before they become critical. **Closing** We acknowledge the impact these instabilities caused and apologize for any inconvenience experienced by our clients and partners during these windows. Transparency regarding what happened is part of our commitment to those who trust our platform. The actions taken in response to these incidents prioritize reinforcing our environment's stability and reducing the likelihood of recurrence. We continue to invest heavily in observability, infrastructure resilience, and incident response processes to ensure an increasingly reliable service. Unico Team

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

   Prezado Cliente, Identificamos uma instabilidade na capacidade de verificação de identidade com orquestração com IDScore, que está apresentando lentidão no retorno do Score de autenticação de determinados processos. Clientes que utilizam orquestração com o Trust podem enfrentar também cenários de erros em determinados processos devido a lentidão identificada. Nossa engenharia já está mobilizada para o diagnóstico e trabalhando na identificação da causa raiz para normalizar o serviço o mais breve possível. No momento, o time técnico realiza análises detalhadas em nossa camada de dados para mitigar o impacto. Reforçamos que novas atualizações serão enviadas em breve. Equipe Unico.

2. 6 июля 2026 г. в 16:51 UTCmonitoring

   Prezado Cliente, Informamos que nossa equipe de tecnologia identificou e solucionou a instabilidade que afetou o tempo de resposta das requisições para retorno do Score de autenticação. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

3. 6 июля 2026 г. в 17:25 UTCresolved

   Prezado Cliente, Incidente resolvido. Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

4. 13 июля 2026 г. в 21:17 UTCpostmortem

   **Post-Mortem: Availability Instability in Identity Processing** **Summary** On two occasions on consecutive days in July 2026, the identity processing service experienced brief drops in availability. These were caused by saturation in a shared database that supports part of the verification flow. Both events were quickly identified by the monitoring teams, mitigated within approximately 30 minutes, and resolved with zero data loss. **Impact** Incident 1 — July 6, 2026, from 13:00 to 13:34 \(BRT\): A sudden and legitimate spike in request volume overloaded the database replica serving the service. Clients using services dependent on verification score generation experienced slowness, as requests were automatically retried instead of returning errors. Verification processes continued to complete successfully, albeit with delays. Incident 2 — July 7, 2026, from 17:52 to 18:05 \(BRT\): A database query lacking a row-return limit was triggered by an edge-case data pattern, saturating the CPU of the same database replica. This increased latency and, for a short window \(around 13 minutes\), caused errors in certain steps of the verification flow for a subset of clients. In both cases, the impact was limited to the windows described above, without total service downtime and with zero data loss. **Root Cause** Both incidents share the same underlying cause: CPU saturation on a relational database replica that serves multiple capabilities of the identity verification service. In the first incident, a specific request volume surged roughly 10x within a few minutes, exceeding the provisioned capacity for the replica. The database infrastructure was not scaled to sustain the peak, leading to processing exhaustion \(CPU scheduling contention\) and a subsequent cascade of timeouts in dependent services. In the second incident, a specific query lacked a limit on returned rows. When executed for a record with an unusual volume of associated images, the query triggered a full table scan and sort, consuming all available processing power on the replica. This effect was amplified by two internal mechanisms that, combined, tripled the number of queries generated per request. **Resolution** In both incidents, the operations teams: Vertically scaled a secondary database replica and redirected traffic to it via a DNS update; Temporarily disabled mechanisms that were generating additional database load; Monitored the stabilization of availability metrics before declaring the incident resolved; Following the second incident, applied a definitive fix to the problematic query \(enforcing a limit on returned records\) and initiated a data-cleansing process for non-standard records that could replicate the scenario. **Lessons Learned** These incidents reinforced the need for defensive and systematic infrastructure design, applying explicit limits and pagination on database queries to eliminate latent risks under atypical traffic. It became evident that component migrations can inadvertently strip away implicit protections against overload. This makes the implementation of declarative resilience mechanisms—such as proper timeouts, circuit breakers, and connection limits—indispensable. Additionally, the scenario highlighted the importance of investigating the root cause of recurring saturation patterns rather than relying solely on point-in-time mitigations, as well as the urgency of monitoring and refactoring architectures that multiply database calls per request to mitigate load amplification risks before they become critical. **Closing** We acknowledge the impact these instabilities caused and apologize for any inconvenience experienced by our clients and partners during these windows. Transparency regarding what happened is part of our commitment to those who trust our platform. The actions taken in response to these incidents prioritize reinforcing our environment's stability and reducing the likelihood of recurrence. We continue to invest heavily in observability, infrastructure resilience, and incident response processes to ensure an increasingly reliable service. Unico Team

1. 2 июля 2026 г. в 22:04 UTCidentified

   Prezado Cliente, Estamos analisando uma degradação em nossa plataforma de atendimento aos clientes, causando instabilidade no atendimento via Whatsapp. Orientamos nossos clientes a enviarem mensagens via formulário, e-mail ou nos contatarem pelo nosso webchat como alternativa de contato síncrono https://business.unico.io/hc/pt-br Em breve retornaremos com novas atualizações.

2. 2 июля 2026 г. в 22:05 UTCidentified

   We are continuing to work on a fix for this issue.

3. 3 июля 2026 г. в 00:04 UTCmonitoring

   Prezado Cliente, Identificamos que a instabilidade que afetava a nossa plataforma de gerenciamento de atendimento foi corrigida. As ações de correção técnica foram executadas com sucesso pelo nosso parceiro e a comunicação do canal via WhatsApp já se encontra reestabelecida. Estamos em monitoramento assistido para garantir a total estabilidade e performance do ambiente. Pedimos desculpas pelo impacto causado em sua operação. Atenciosamente, Equipe Unico

4. 3 июля 2026 г. в 01:14 UTCresolved

   Prezado Cliente, O incidente que causava instabilidade no canal de atendimento via WhatsApp foi totalmente resolvido. A causa do problema foi identificada e a correção definitiva já foi aplicada em produção junto ao nosso parceiro de tecnologia. A integração com a plataforma foi restabelecida e o nosso time de atendimento já está operando e respondendo normalmente. Agradecemos a parceria e a paciência de todos durante o período de manutenção do canal. Atenciosamente, Equipe Unico

5. 13 июля 2026 г. в 20:36 UTCpostmortem

   ### **Postmortem: WhatsApp Support Channel Instability** #### **Summary** On July 2, 2026, an instability affected our WhatsApp customer support channel. During this period, automated messages from our virtual assistant \(bot\) were not being delivered to end-users. Service was fully restored after the identification and rollback of a system change within our technology partner’s environment. #### **Impact** This incident exclusively impacted customers attempting to reach support through our WhatsApp channel. While automated messages managed by the bot failed to deliver, manual messages sent by human agents continued to operate normally. Our alternative support channels, such as email and webchat, remained fully operational and were communicated as active alternatives during the instability. #### **Root Cause** The root cause was an update deployed in the messaging service managed by our technology partner. This update introduced an incompatibility within the partner's own production environment configurations. This supplier-side infrastructure failure disrupted the automated communication flow, preventing the bot from delivering messages. #### **Resolution** Our partner's technical team investigated the issue within their environment and traced the failure back to the recently deployed update. The resolution applied by the vendor consisted of performing an immediate rollback to the previous stable version of their messaging service. Once the partner completed this rollback, message delivery was successfully restored, and our support channel returned to normal operations. #### **Lessons Learned** This incident reinforced the importance of maintaining an agile contingency and communication strategy to quickly redirect our customers to alternative channels \(such as webchat and forms\) during third-party service outages. Additionally, it highlighted the need to continuously align with our key vendors regarding the requirement for more rigorous validation and testing protocols in their own environments before promoting updates that can impact our operations.

1. 26 июня 2026 г. в 14:10 UTCresolved

   Prezado cliente, Entre 00:17 e 10:40 de 26/06, identificamos uma instabilidade que causou falhas de acesso na plataforma SafeDoc (através do endereço seu.acesso.io) para um grupo específico de clientes. Durante esse período, alguns usuários enfrentaram dificuldades no fluxo de login, processamento e visualização de imagens e arquivos. A origem do comportamento esteve relacionada a uma atualização programada de manutenção executada na noite de 25/06, que gerou incompatibilidade na parametrização de algumas instâncias do sistema. Nossos times de Engenharia e SRE identificaram o cenário e aplicaram as correções e ajustes de configuração necessários nas instâncias afetadas. O serviço foi restabelecido e está operando normalmente. Lamentamos o ocorrido e seguimos monitorando o comportamento da plataforma para garantir a estabilidade das operações. Em caso de dúvidas, nossa equipe de CX está à disposição. Equipe Unico.

2. 3 июля 2026 г. в 18:22 UTCpostmortem

   **Resumo** No dia 26 de junho de 2026, entre 00:17 e 10:40 \(horário de Brasília\), um grupo de clientes enfrentou instabilidade que afetou o acesso a alguns de nossos serviços. A falha se manifestou em erros de login, processamento e acesso a arquivos. Nossa equipe de engenharia identificou a causa e restaurou o serviço para todos os clientes afetados. **Impacto** Durante o incidente, que durou aproximadamente 10 horas e 23 minutos, 24 clientes ficaram impossibilitados de utilizar funcionalidades essenciais de nossos serviços, impactando suas operações. O acesso foi completamente restabelecido às 10:40 do dia 26 de junho de 2026. **Causa Raiz** A causa raiz do incidente foi uma falha durante um processo de atualização programada de sistema, que ocorreu na noite do dia 25 de junho. A atualização de configuração não foi aplicada corretamente em um subconjunto de servidores, fazendo com que o sistema fizesse referência a dependências de software desatualizadas e incompatíveis. Essa falha impediu a comunicação correta com serviços de armazenamento em nuvem e de autenticação, resultando nos erros observados pelos clientes. A ausência de validação automatizada pós-implantação e de alertas centralizados para este tipo de erro de configuração impediu a detecção proativa do problema. **Resolução** Assim que o incidente foi reportado na manhã do dia 26 de junho, nossa equipe de prontidão foi acionada. Foi identificado que a falha estava relacionada a uma implantação incorreta de arquivos de configuração. As equipes de engenharia aplicaram as correções necessárias em todas as instâncias afetadas, restaurando a funcionalidade completa dos serviços. Após a aplicação da correção, foi realizada uma verificação completa para garantir que todos os sistemas estivessem operando normalmente. **Lições Aprendidas** * Automação na validação: Implementações em larga escala exigem verificações automatizadas pós-implantação para garantir que todas as instâncias tenham sido atualizadas corretamente e de forma consistente. * Observabilidade centralizada: É fundamental garantir que os registros de erros de todas as aplicações sejam transmitidos para uma plataforma centralizada, permitindo a detecção rápida de anomalias, mesmo que a falha afete a própria capacidade de comunicação da aplicação. Estamos comprometidos com a confiabilidade de nossos serviços e continuaremos trabalhando para fortalecer nossos sistemas e processos.

1. 24 июня 2026 г. в 18:20 UTCidentified

   Prezado Cliente, Detectamos um impacto nas requisições com o fluxo do IDTrust, causando instabilidade aos clientes Mexico que utilizam essa capacidade. A nossa equipe de tecnologia está analisando o ambiente e as métricas para determinar a causa e a solução. Retornamos em breve com atualizações. Atenciosamente, Equipe Unico

2. 24 июня 2026 г. в 18:31 UTCmonitoring

   Prezado Cliente, Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

3. 24 июня 2026 г. в 18:53 UTCresolved

   Prezado Cliente, Incidente resolvido. Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

4. 13 июля 2026 г. в 19:27 UTCpostmortem

   **Summary** On June 24, 2026, between 2:55 PM and 3:26 PM \(Brasília time\), the availability indicator for the process creation flow dropped below 95%, with a total duration of approximately 31 minutes. The incident was caused by an instability in an infrastructure provider used in the risk assessment flow, which began returning errors and latency above expected levels. The impact was concentrated on users from Mexican market clients. **Impact** Users of the process creation and authentication flows that relied on the risk assessment step received timeout errors during the period. The impact was more severe for Mexican market clients but also affected authentication flows for other clients. **Root Cause** The root cause was an instability in the infrastructure provider responsible for the risk assessment step. The provider began operating with latency well above normal and returning errors, causing requests that depended on this step to become blocked and propagate failures to the process creation and authentication flows. Internal services were unable to isolate the impact of the provider's degradation, resulting in widespread unavailability for all users passing through this step. **Resolution** The infrastructure provider stabilized on its own at 3:16 PM. The team identified a timeout configuration need during the incident and opened a correction with explicit values. The incident was closed at 3:50 PM after stability was confirmed. **Lessons Learned** The incident highlighted the need to strengthen isolation mechanisms between internal services and infrastructure providers, so that isolated instabilities do not propagate to end users. As follow-ups, the team identified improvements in the resilience of the affected flows and in the documentation of critical dependencies, aiming to reduce response time and impact in future occurrences of a similar nature.

1. 23 июня 2026 г. в 01:24 UTCinvestigating

   Презадо Клиенте, Nossa monitoração proativa detectou um comportamento irregular no ID Pay e no fluxo de onboarding do ByUnico. Embora a causa exata ainda esteja sob investigação, isso pode se manifestar como lentidão ou intermitência no serviço. A equipe de tecnologia está executando todos os procedimentos de diagnóstico no ambiente para identificar as causas. Em breve retornamos com atualizações.

2. 23 июня 2026 г. в 01:39 UTCidentified

   Презадо Клиенте, Nossa equipe ainda está investigando a causa raiz do problema. Em breve traremos mais atualizações. Agradecemos a compreensão.

3. 23 июня 2026 г. в 01:53 UTCidentified

   Презадо Клиенте, Informamos que nossa equipe identificou a causa da instabilidade e está ativamente trabalhando na aplicação da solução. Seguimos empenhados em restabelecer o serviço o mais rapidamente possível e manteremos você informado sobre a evolução. Novas atualizações serão enviadas em breve.

4. 23 июня 2026 г. в 02:18 UTCmonitoring

   Презадо Клиенте, Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

5. 23 июня 2026 г. в 02:41 UTCresolved

   Презадо Клиенте, Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

6. 14 июля 2026 г. в 13:58 UTCpostmortem

   ** Резюме** 22 июня 2026 года в 9:52 вечера (время Бразилиа) поток сохранения документа стал недоступен из-за исчерпания последовательного лимита идентификатора в базе данных. С этого момента все операции по вставке документов начали выходить из строя, каскадируя ошибки в несколько зависимых сервисов. Инцидент длился около 86 минут. ** Воздействие** Одновременно пострадали несколько критически важных сервисов, включая потоки на борту, создание процессов, аутентификацию и платежи. В некоторых потоках доступность упала ниже 3%. Клиенты сталкивались с ошибками или задержками при попытке выполнения операций, которые зависели от сохранения документов. **Корневая причина** Корневая причина была связана с 32-битным типом идентификатора, используемым в таблице документов, который поддерживает примерно 2,1 миллиарда значений; при естественном росте рекордного объема с течением времени этот предел был достигнут, в результате чего база данных больше не могла генерировать новые идентификаторы, поэтому все операции вставки начали выходить из строя. Поскольку не было никакого мониторинга, сконфигурированного для отслеживания близости к этому пределу, истощение произошло внезапно и без предварительного предупреждения. ** Резолюция** Команда определила первопричину примерно за 20 минут. В качестве немедленного смягчения, последовательный идентификатор был переконфигурирован для использования отрицательного диапазона того же типа данных, освобождая примерно еще 2,1 миллиарда значений без каких-либо структурных изменений в базе данных. Решение было проверено в более низких средах перед применением к производству. Служба начала стабилизироваться вскоре после применения исправления и контролировалась до полного восстановления. *Уроки выучены* Инцидент подчеркивает важность осуществления мониторинга для последовательного использования идентификаторов в больших объемах таблиц, с ранними оповещениями, которые позволяют обрабатывать исчерпание в качестве запланированного обслуживания; принятие 8-байтовых типов идентификаторов с самого начала для таблиц с большим объемом записи, включая эту проверку в процессах обзора схемы; и картирование и документирование критических зависимостей основных служб сохранения, чтобы оценить влияние и более быстро расставить приоритеты связи с пострадавшими пользователями в будущих инцидентах.

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

1. 19 июня 2026 г. в 13:08 UTCinvestigating

   Prezado Cliente, Estamos analisando uma degradação em nossa plataforma de atendimento aos clientes, causando instabilidade no atendimento via Whatsapp. Orientamos nossos clientes a enviarem mensagens via formulário, e-mail ou nos contatarem pelo nosso webchat como alternativa de contato síncrono https://business.unico.io/hc/pt-br/p/help-u Em breve retornaremos com novas atualizações.

2. 19 июня 2026 г. в 18:34 UTCmonitoring

   Prezado Cliente, Identificamos que a instabilidade que afetava a nossa plataforma de gerenciamento de atendimentos foi corrigida. As ações de correção técnica foram executadas com sucesso pelo nosso parceiro e a comunicação do canal via WhatsApp já se encontra reestabelecida. Neste momento, nosso time de engenharia e operações segue em monitoramento assistido para garantir a total estabilidade e performance do ambiente. Pedimos desculpas pelo impacto causado em sua operação. Atenciosamente, Equipe Unico

3. 19 июня 2026 г. в 19:42 UTCresolved

   Prezado Cliente, O incidente que causava instabilidade no canal de atendimento via WhatsApp foi totalmente resolvido. A causa do problema foi identificada e a correção definitiva já foi aplicada em produção junto ao nosso parceiro de tecnologia. A integração com a plataforma foi restabelecida e o nosso time de atendimento já está operando e respondendo normalmente. Agradecemos a parceria e a paciência de todos durante o período de manutenção do canal. Atenciosamente, Equipe Unico

4. 3 июля 2026 г. в 20:36 UTCpostmortem

   **Sumário** No dia 19 de junho de 2026, identificamos uma instabilidade que afetou nosso canal de atendimento via WhatsApp. O incidente, que teve início aproximadamente às 09:00 e foi resolvido às 15:45 \(horário de Brasília\), impediu que nossos agentes acessassem as conversas dos clientes nessa plataforma. A causa raiz foi um problema técnico originado em um de nossos parceiros de tecnologia, que já foi corrigido. **Impacto** Durante o período do incidente, o atendimento aos clientes finais através do canal de WhatsApp foi impactado. Como alternativa, os clientes foram orientados a utilizar nossos outros canais de contato, como formulário, e-mail e webchat. As operações foram normalizadas no mesmo dia. **Causa Raiz** A investigação, conduzida em conjunto com nosso parceiro tecnológico responsável pela plataforma de gestão de conversas, revelou que a causa do incidente foi uma alteração de certificados de segurança em um sistema terceiro com o qual a plataforma se integra. Essa alteração invalidou o mecanismo de autenticação utilizado pelo serviço, impedindo a comunicação entre a plataforma de atendimento e o canal do WhatsApp. A detecção do problema foi reativa, pois a falha de autenticação não gerava alertas proativos e o ambiente de testes não utiliza os mesmos certificados do ambiente de produção, o que impediu a reprodução do erro em testes preliminares. **Resolução** Após a identificação do problema, a equipe de engenharia do nosso parceiro tecnológico atualizou os certificados de autenticação em seus sistemas para restabelecer a compatibilidade com a plataforma terceira. A correção foi aplicada e validada, normalizando o acesso dos nossos agentes às conversas e restaurando completamente o serviço de atendimento via WhatsApp às 15:45. **Lições Aprendidas** * É crucial manter uma comunicação ativa e monitorar os canais de parceiros tecnológicos para se antecipar a mudanças que possam impactar os serviços integrados. * Falhas de autenticação com serviços externos são um ponto crítico e devem possuir mecanismos de alerta específicos para permitir uma detecção e resposta mais rápidas, reduzindo o tempo de indisponibilidade. Estamos empenhados em garantir a estabilidade e a qualidade de nossos canais de atendimento e continuaremos a trabalhar em estreita colaboração com nossos parceiros para fortalecer a resiliência de nossos serviços.

1. 12 июня 2026 г. в 15:29 UTCidentified

   Prezado Cliente, Estamos acompanhando uma instabilidade na plataforma de mensageria de WhatsApp, junto à Meta, que está gerando indisponibilidade no envio de links para usuários finais nos produtos IDCloud (By unico) e ID Pay que utilizam o fluxo com o WhatsApp. Notificações via e-mail e sms estão funcionando normalmente. Maiores informações sobre incidente da Meta: https://metastatus.com/ Em breve retornaremos com novas atualizações.

2. 12 июня 2026 г. в 17:03 UTCidentified

   Prezado Cliente, Seguimos acompanhando a instabilidade na plataforma de mensageria de WhatsApp, junto à Meta, que está gerando indisponibilidade no envio de links para usuários finais nos produtos IDCloud (By unico) e ID Pay que utilizam o fluxo com o WhatsApp. Notificações via e-mail e sms estão funcionando normalmente. Maiores informações sobre incidente da Meta: https://metastatus.com/ Em breve retornaremos com novas atualizações

3. 12 июня 2026 г. в 18:17 UTCmonitoring

   Prezado Cliente, As ações corretivas para o incidente foram executadas junto ao nosso parceiro. Nosso time está em monitoramento assistido acompanhando a performance do ambiente. Pedimos desculpas pelo ocorrido e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico

4. 12 июня 2026 г. в 18:31 UTCresolved

   Prezado Cliente, Incidente resolvido. As ações corretivas para o incidente foram executadas junto ao nosso parceiro. Nosso time está em monitoramento assistido acompanhando a performance do ambiente. Pedimos desculpas pelo ocorrido e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico

1. 12 июня 2026 г. в 14:58 UTCidentified

   Prezado Cliente, Estamos analisando uma degradação em nossa plataforma de atendimento aos clientes, causando instabilidade no atendimento via Whatsapp. Orientamos nossos clientes a enviarem mensagens via e-mail ou nos contatarem pelo nosso webchat como alternativa de contato sincrono https://business.unico.io/hc/pt-br/p/help-u Em breve retornaremos com novas atualizações.

2. 12 июня 2026 г. в 17:31 UTCmonitoring

   Prezado Cliente, As ações corretivas para o incidente foram executadas pelo nosso parceiro. Nosso time está em monitoramento assistido acompanhando a performance do ambiente. Pedimos desculpas pelo ocorrido Atenciosamente, Equipe Unico

3. 12 июня 2026 г. в 18:00 UTCresolved

   Prezado Cliente, Incidente resolvido. as ações corretivas para o incidente foram executadas junto ao nosso parceiro. Nosso time está em monitoramento assistido acompanhando a performance do ambiente. Pedimos desculpas pelo ocorrido e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico