Histórico de interrupções do Unico

1. 30 Eost 2026 da 02:35 UTCinvestigating

   Caro Cliente, Por volta das 23h00 (BRT) na sexta-feira, 29 de agosto de 2026, identificamos uma instabilidade que afeta a criação do processo no IDCloud. Durante este período, algumas solicitações podem falhar ou experimentar tempos de resposta mais lentos do que o habitual. Reconhecemos o inconveniente que isto pode causar e apreciamos a sua compreensão. Uma nova atualização será fornecida em breve. Equipa Unico

2. 30 Eost 2026 da 02:49 UTCidentified

   Nossa equipe de engenharia mapeou a origem da instabilidade que afeta a criação do processo no IDCloud. A equipe técnica já começou a aplicar medidas corretivas, incluindo o dimensionamento de recursos na camada afetada e o monitoramento contínuo de indicadores-chave. Restaurar o serviço está sendo tratado com prioridade máxima e total mobilização de engenharia. Reiteramos que novas atualizações serão enviadas em breve. Equipa Unico

3. 30 Eost 2026 da 02:57 UTCmonitoring

   Caro Cliente, Nossa equipe de engenharia realizou as ações corretivas necessárias para resolver a instabilidade que afeta a criação do processo no IDCloud. O ambiente voltou à estabilidade, com indicadores de disponibilidade e tempo de resposta restaurados aos níveis operacionais normais a partir das 11:48 PM (BRT). O serviço está disponível para uso normal. Neste momento, nossa equipe técnica permanece sob monitoramento assistido, observando de perto o ambiente para garantir desempenho consistente e agir imediatamente em caso de qualquer flutuação. Agradecemos sua compreensão e reiteramos que novas atualizações serão enviadas em breve. Equipa Unico

4. 30 Eost 2026 da 03:15 UTCresolved

   Caro Cliente, Resumo Executivo e Impacto Entre 23:00 e 11:48 (BRT) em 29 de agosto de 2026, uma falha afetou a criação do processo em IDCloud. Durante esta janela, alguns clientes usando esses fluxos experimentaram falhas e aumentaram os tempos de resposta, com propagação para viagens dependentes, incluindo autenticação, captura de documentos e entrega de notificações. Não houve comprometimento com a integridade ou segurança das informações processadas e nenhum dado foi perdido. Os indicadores retornaram aos níveis operacionais normais às 11:48 PM (BRT), com normalização confirmada tanto em nosso monitoramento quanto no lado do cliente, cobrindo a criação e a conclusão do processo. Causa raiz e resolução A origem foi identificada em nossa camada de dados: uma rotina de manutenção interna ficou presa, e as operações de aplicação começaram a filar por trás até que o limite de conexão disponível estivesse esgotado, reduzindo a capacidade de processamento. A nossa equipa de engenharia terminou cirurgicamente apenas a rotina presa, liberando imediatamente a fila. Conexões e capacidade de processamento foram totalmente restauradas, sem alterações de dados. Compromisso e Próximos Passos Nossa equipe de engenharia se concentrará em três frentes: limitar os tempos de espera para rotinas de manutenção interna, impedir que rotinas concorrentes funcionem contra a mesma estrutura e fortalecer a resiliência do serviço às flutuações na camada de dados. Uma autópsia detalhada, incluindo o calendário completo e um plano de ação com prazos, será compartilhada em breve. Pedimos sinceras desculpas pelo impacto em suas operações e permanecemos disponíveis através de nossos canais de suporte. Equipa Unico

Traduzido automaticamente da atualização oficial do incidente.

1. 10 Eost 2026 da 20:26 UTCidentified

   Caro cliente, Detectamos um impacto em alguns pedidos do IDCloud, afetando a capacidade do Behavior Alert (IDTrust) e o fluxo 1:N. Essa instabilidade também pode afetar os clientes no México que usam essa capacidade. Nossa equipe de engenharia é mobilizada para resolver o problema o mais rápido possível. Vamos fornecer novas atualizações em breve.

2. 10 Eost 2026 da 20:29 UTCmonitoring

   Nossa equipe de engenharia identificou e implementou as ações necessárias para resolver a instabilidade nas capacidades de fluxo do IDCloud afetadas. Neste momento, a equipe técnica está realizando uma análise detalhada da nossa camada de dados e continua a monitorar o ambiente. Reiteramos que novas atualizações serão enviadas em breve.

3. 10 Eost 2026 da 21:01 UTCresolved

   Resumo Executivo e Impacto Por volta das 17h08, um alerta automatizado detectou uma queda de disponibilidade no serviço de reconhecimento facial (1:N fluxo), desencadeando o incidente. A questão se agravou rapidamente e passou a afetar o comportamento do serviço de alerta e, posteriormente, o fluxo de criação do processo, devido aos intervalos de tempo em cascata entre esses serviços. O impacto afetou um subconjunto de clientes usando essas capacidades. A situação foi relatada como estabilizada às 17h22, com métricas retornando aos níveis normais. Causa raiz e resolução A causa raiz foi um pico de tráfego gerado por uma carga de trabalho interna, que enviou um alto volume de pedidos de reconhecimento facial diretamente para o pipeline biométrico, contornando a camada de borda utilizada pelo tráfego normal do cliente. Esse volume adicional saturou a capacidade do banco de dados de apoio ao serviço de reconhecimento facial. A saturação causou intervalos de tempo nesse serviço, que em cascata para o serviço de orquestração do motor biométrico, depois para o serviço de alerta de comportamento, e finalmente para o fluxo de criação de processo usando essas capacidades. Para resolver o problema, a equipe parou a carga de trabalho responsável pelo pico e aumentou a capacidade do banco de dados afetado. Essas ações atenuaram o problema, com o volume de erro retornando aos níveis quase zero. Compromisso e Próximos Passos Um item de seguimento foi aberto para implementar taxa limitante para o tipo de carga interna que causou o pico, como medida preventiva contra recorrência. O aumento de capacidade para a base de dados afetada já foi realizado durante o próprio incidente.

4. 25 Eost 2026 da 13:05 UTCpostmortem

   **Resumo** Em 10 de agosto de 2026, entre 5:08 PM e 5:27 PM \(Brasília time\), o indicador de disponibilidade para o fluxo de reconhecimento facial 1:N caiu abaixo de 95%, com impacto total de aproximadamente 19 minutos. O incidente foi causado pela saturação do banco de dados de busca vetorial utilizado pelo motor biométrico, resultante do comportamento inesperado no mecanismo de consumo da fila, que gerou um volume de chamada 2,36 vezes maior do que configurado. O excesso de carga atingiu o limite máximo de escala da base de dados, causando intervalos de tempo em cascata em vários serviços dependentes e afetando 55 usuários clientes com erros durante o período. **Impacto Os usuários do reconhecimento facial, autenticação e criação de processos fluiram de múltiplos clientes experimentados erros e timeouts durante o período. A saturação do banco de dados em cascata através dos serviços biométricos de orquestração, motor e criação de processos. A atenuação foi realizada por desativação de um serviço interno e aumento do limite máximo de escala do banco de dados, estabilizando o serviço às 17h27. **Root Cause** A causa raiz foi uma combinação de fatores relacionados ao comportamento do serviço e à capacidade da infraestrutura envolvida. O serviço foi configurado com um limite de 2 solicitações por segundo, mas o mecanismo de consumo da fila se comportou inesperadamente: mensagens cujo processamento excedeu o prazo de reconhecimento foram reenviadas pela fila sem cancelar a execução original — transformando 938 itens de trabalho em 2.217 chamadas efetivas \(~8.4 RPS\). Esse tráfego ampliado chegou ao banco de dados sem passar pela camada de proteção de bordas, que normalmente limitaria o volume de solicitação, uma vez que o caminho de rede utilizado nesse fluxo não passou por esses controles. O banco de dados, já operando próximo ao seu limite máximo de escala, não foi capaz de absorver a carga adicional — sua CPU atingiu 88% enquanto escalonava até o teto configurado de 100 nós — e a latência da consulta saltou de ~3 segundos para ~18,75 segundos em p90, propagando timeouts em toda a cadeia de serviços dependentes. **Resolução** A equipe identificou o processo em questão como a fonte da carga dentro de poucos minutos do alerta. O processo foi desativado, e o limite máximo de escala do banco de dados foi aumentado de 100 para 150 nós. Com essas duas ações, o serviço estabilizou às 17h27. ** Lessons learn ** O incidente mostrou que a limitação de taxa aplicada apenas no lado da publicação de mensagens é insuficiente quando o consumidor pode ampliar o volume através da redelivery. Os controlos de taxa e de concorrência também têm de existir do lado do consumo. Além disso, os serviços internos que acessam componentes críticos através de caminhos que contornam as proteções de bordas representam um risco estrutural — qualquer cliente interno pode gerar carga descontrolada na infraestrutura compartilhada.

Traduzido automaticamente da atualização oficial do incidente.

1. 31 Gouere 2026 da 12:42 UTCinvestigating

   Prezados clientes, 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 destinos continuam recebendo econseguindo assinar os arquivos. No entanto, o registro do envio pode ser temporário não ser exibido na lista de acompanhamento do acolhimento. Nossa equipe de engenharia já está funcionando para corrigir a exposição na interface e restabelecer o histórico no painel o mais breve possível. Pedimos desculpas pelo inconveniente e manteremos todos os informados sobre o progresso. Atenciosamente,

2. 31 Gouere 2026 da 13:08 UTCidentified

   Prezados clientes, 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 correlação para restabelecer a exposição correta de todos os envios na interface do remetente. Lembramos que o processo, envio e assinatura dos documentos continua operando normalmente. Volataremos com uma nova atualização assim que a correlação for concluída e entrarmos na fase de monitoramento. Atenciosamente,

3. 31 Gouere 2026 da 13:20 UTCmonitoring

   Prezados clientes, Informação que a execução para a exposiçã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 Gouere 2026 da 14:06 UTCresolved

   Prezados clientes, Informação que o incidente relacionado à exposição de envios no painel de acompanhamento foi oficialmente encerrado. Após a aplicação da correlação e o período de monitoramento, confirmamos que a listagem e o histórico de documentos foram totalmente restaurados, e a plataforma opera em completa estabilidade. Agradamos pela compreensão e paciência de todos durante o processo. Atenciosamente,

Traduzido automaticamente da atualização oficial do incidente.

1. 29 Gouere 2026 da 14:04 UTCresolved

   Resumo Executivo & Impacto Gostaríamos de informar que o incidente que afeta temporariamente o serviço de notificação ID Cloud Webhook foi resolvido. Período de Impacto: De 08:32 a 10:05. Impacto da Plataforma: A instabilidade foi estritamente limitada à entrega de notificações Webhook, resultando em um atraso na distribuição de mensagens. Não houve degradação da plataforma principal, nenhuma falha no motor de liveness, e nenhuma perda de dados. Impacto do Cliente: A questão afetou uma pequena parcela dos clientes. Os clientes que implementaram um fluxo de votação GET como contingência (fallback) não tiveram nenhum tempo de inatividade ou impacto operacional. Causa e Resolução da Raiz Causa raiz: A instabilidade foi desencadeada por uma atualização de recursos no ambiente. Um desencontro temporário nas permissões de acesso entre a fila de tarefas e a rota de destino fez com que as solicitações fossem negadas, levando a um atraso temporário de notificações. Ação resolutiva: A equipe técnica completou o redirecionamento de tráfego para o novo ambiente, restaurando a comunicação adequada entre componentes e liberando o backlog de Webhooks. O processamento voltou ao normal, e a fila de envio foi totalmente limpa. Compromisso & Próximos Passos A estabilidade dos nossos serviços é a nossa maior prioridade. Para garantir total transparência e evitar recorrência, nossa equipe de engenharia se concentrará nas seguintes frentes: Postmortem detalhada: Um relatório abrangente com uma análise aprofundada da causa raiz e um plano de ação preventiva será preparado. Melhorias da observábilidade: Ajustaremos as métricas de monitoramento para garantir uma maior visibilidade dos erros de comunicação entre serviços durante os cenários de transição. Pedimos sinceramente desculpas pela inconveniência e continuamos disponíveis para quaisquer esclarecimentos adicionais. Atenciosamente, Unico Team

2. 7 Eost 2026 da 13:08 UTCpostmortem

   **Summary** On July 29, 2026, between 8:32 AM and 10:05 AM \(Brasília time\), the webhook delivery service was degraded for approximately 1 hour and 33 minutes. The incident was caused by a planned infrastructure migration that created a transient incompatibility state: after internal routes were switched to the new cluster, the webhook service began generating authentication tokens from the new cluster, but deliveries were still being directed to the old cluster — which rejected the tokens with an authorization error. Lost events were reprocessed on demand. **Impact** Multiple products were affected simultaneously — including authentication, payments, and onboarding flows. Users of clients that relied exclusively on webhook notifications to continue their business flows experienced operational interruptions during the period. Clients that had implemented active polling as a fallback mechanism experienced reduced impact. **Root Cause** The root cause was identified in the migration planning: the procedure did not map the chained dependency of the webhook flow — where the internal route creates an asynchronous task that, in turn, calls the public route for delivery. By migrating the internal routes and the public routes in separate steps, an incompatibility window was created where tokens generated by the new cluster were rejected by the old cluster's authorization policy, which specifically validated the previous service account identifier. This scenario was not identified during the change's risk assessment, and none of the existing service quality indicators covered the asynchronous delivery layer where the failure materialized. **Resolution** The team identified the token incompatibility as the source of the failures and completed the migration of the public routes to the new cluster, eliminating the divergence. From that point on, the pending deliveries in the queue began processing normally. The impact ceased at 10:05 AM, and traffic on the old cluster reached zero at 10:32 AM. **Lessons Learned** The incident showed that migrations involving chained asynchronous delivery flows require all routes participating in the chain — internal and public — to be migrated in a coordinated manner, without incompatibility windows between clusters. The gradual approach used, while suitable for most migrations, created a prolonged failure period here that could have been avoided with an atomic transition or a much shorter transition window. Additionally, the lack of observability at the asynchronous delivery layer was the reason the incident was not detected internally — existing indicators measured only event acceptance, not actual delivery. Creating dedicated alerts for failures and backlog at this layer is the most urgent monitoring improvement identified.

Traduzido automaticamente da atualização oficial do incidente.

1. 24 Gouere 2026 da 21:47 UTCinvestigating

   Caro Cliente, Atualmente estamos investigando uma instabilidade em nossos Webhooks que está afetando a latência na entrega de dados. Nossa equipe de engenharia está trabalhando ativamente para resolver o problema o mais rápido possível. Vamos fornecer novas atualizações em breve.

2. 24 Gouere 2026 da 21:53 UTCmonitoring

   Caro Cliente, Nossa equipe de engenharia identificou e implementou as ações necessárias para resolver a instabilidade do Webhook que afeta a latência da entrega de dados. Neste momento, a equipe técnica está realizando uma análise detalhada da nossa camada de dados e continua a monitorar o ambiente. Reiteramos que novas atualizações serão enviadas em breve.

3. 24 Gouere 2026 da 22:18 UTCresolved

   Resumo Executivo e Impacto A partir das 18h05 (hora de Brasília), ocorreu uma instabilidade no serviço Webhook, levando à falha no processamento de eventos e na entrega de notificações para operações afetadas durante esse período. Causa raiz e resolução O incidente foi causado por um problema com uma Conta de Serviço compartilhada usada em vários serviços, resultando em falhas de autenticação. Ao identificar a causa raiz, a equipe de engenharia restaurou as credenciais e configurações necessárias. A operação normal foi totalmente restabelecida às 6:29 PM (BRT). Compromisso e Próximos Passos Como parte da melhoria contínua e mitigação dos riscos, a equipe de engenharia analisará as dependências de recursos e o gerenciamento de acesso entre os serviços. Isso impedirá problemas de configuração semelhantes em futuros ajustes de infraestrutura.

4. 3 Eost 2026 da 20:00 UTCpostmortem

   **Resumo** Em 24 de julho de 2026, entre 6:05 e 6:29 \(Brasília time\), o serviço de criação e entrega do webhook estava indisponível por aproximadamente 24 minutos. O incidente foi causado pela perda de acesso a uma conta de serviços de infraestrutura durante um processo de desactivação de recursos ligado a uma migração de cluster realizada dias antes. A conta afetada foi compartilhada por vários serviços sem que essa dependência fosse documentada, fazendo com que o serviço webhook perdesse sua capacidade de autenticação e parasse de criar e entregar eventos. **Impacto A criação e entrega do evento Webhook foi interrompida durante o período, afetando 18 usuários com mais de 1.550 erros registrados. O impacto em cascata para outros serviços que dependiam do mesmo fluxo de autenticação, causando degradação simultânea em diferentes capacidades da plataforma. **Root Cause** A causa raiz foi identificada na configuração de dependência do serviço. Esta dependência entre serviços não foi documentada nem visível em qualquer mapeamento de dependência. Quando o processo de desmantelamento removeu a conta como parte da limpeza de recursos do serviço original, não houve validação automatizada para verificar se a conta ainda estava sendo utilizada por outros serviços ativos. A ausência desta salvaguarda manteve a dependência oculta até que a sua remoção causou falhas de autenticação generalizadas. **Resolução** A equipe rapidamente identificou a conta de serviço instável como a fonte das falhas de autenticação. A conta foi ajustada manualmente e aplicada ao cluster, restaurando o serviço às 6:29 PM. A duração total do impacto foi de aproximadamente 24 minutos. ** Lessons learn ** O incidente expôs os riscos de configurações legadas que criam dependências ocultas entre serviços: uma única mudança de recursos durante a manutenção planejada foi suficiente para interromper vários serviços simultaneamente. O processo de desmantelamento dos recursos de infra-estrutura deve incluir a validação automatizada da dependência antes de qualquer alteração.

Traduzido automaticamente da atualização oficial do incidente.

1. 21 Gouere 2026 da 16:39 UTCidentified

   Caro cliente, Estamos investigando uma instabilidade nas funcionalidades do IDCloud que afeta os fluxos de autenticação na jornada de processo, impactando especificamente a Web Journey (anteriormente ByUnico). Nossa equipe de engenharia é mobilizada para resolver o problema o mais rápido possível. Vamos fornecer novas atualizações em breve.

2. 21 Gouere 2026 da 16:49 UTCmonitoring

   Caro Cliente, Nossa equipe de engenharia identificou e implementou as ações necessárias para resolver a instabilidade nas capacidades de fluxo do IDCloud afetadas. Neste momento, a equipe técnica está realizando uma análise detalhada da nossa camada de dados e continua a monitorar o ambiente. Reiteramos que novas atualizações serão enviadas em breve.

3. 21 Gouere 2026 da 18:02 UTCresolved

   Resumo Executivo e Impacto A partir de aproximadamente 12:44 PM (hora de Brasília) em 21 de julho de 2026, uma parcela dos usuários na jornada de bordo reduzida experimentou carregamento mais lento das telas iniciais no fluxo. O impacto foi observado em todos os ambientes onde essa jornada é utilizada, afetando a velocidade percebida e, em menor grau, a capacidade dos usuários de completar o processo durante esse período. Causa raiz e resolução A investigação está em curso para confirmar a causa raiz definitiva do incidente. Não houve impacto nos servidores, na rede ou na infraestrutura — o problema foi confirmado como isolado à experiência na tela no dispositivo do usuário. Como medida de contenção, a equipe responsável aplicou um ajuste preventivo às 1:39 PM (BRT) e os tempos de carregamento retornaram ao normal em poucos minutos. A análise para validar e confirmar a causa raiz ainda está sendo realizada pela equipe técnica. Compromisso e Próximos Passos Como parte da melhoria contínua dos processos de resposta a incidentes, a equipe se compromete a melhorar o fluxo de escalada automática para equipes responsáveis, tornando a ativação ainda mais direta e efetiva a partir do momento em que um incidente é aberto. Além disso, o monitoramento da velocidade de carregamento será reforçado durante o lançamento de novas mudanças nesta jornada, com o objetivo de identificar e corrigir regressões potenciais ainda mais rápidas, minimizando o impacto dos usuários em situações semelhantes.

4. 3 Eost 2026 da 14:01 UTCpostmortem

   **Resumo** Em 21 de julho de 2026, entre 12:44 PM e 1:43 PM \(Brasília time\), indicadores de desempenho de carga de página para a viagem reduzida degradaram-se severamente, com tempo médio de carga saltando de ~4,8s para ~8,9s e o p95 atingindo 31,5 segundos. O incidente foi causado pela limitação de taxa aplicada pela infraestrutura de nuvem em conexões originadas do provedor, o que impediu o carregamento de ativos de frontend. **Impacto Usuários de 32 clientes experimentaram cargas de página extremamente lentas ou falhas de carregamento completas, com aproximadamente 94 erros de viagem registrados. Erros de tempo limite de inicialização — desencadeados quando o aplicativo não consegue montar em 30 segundos — atingiram cerca de 23 mil ocorrências durante o período. **Root Cause** A causa raiz foi identificada na camada de rede da infraestrutura: o provedor de CDN consolida o tráfego através de um conjunto limitado de endereços IP de saída. Um pico em novas conexões TCP e apertos de mão TLS originados desses IPs desencadeou os mecanismos automáticos de defesa da camada de rede da infraestrutura de nuvem, que começaram a limitar as taxas mesmo antes do processamento HTTP. Porque essas falhas ocorreram na camada de rede — antes do processamento HTTP — elas não apareceram em registros de solicitação padrão, tornando o problema invisível ao monitoramento convencional e dificultando significativamente o diagnóstico. **Resolução** O impacto cessou com a recuperação natural da taxa limite aplicada pela infraestrutura de nuvem. A desativação de um componente, inicialmente sinalizada como uma possível causa, coincidiu temporalmente com a recuperação, mas foi posteriormente confirmada como não relacionada ao incidente. As correções de configuração – habilitando o HTTP Keep-Alive com um tempo- limite estendido e adicionando uma regra de permissão para IPs CDN na camada de proteção de borda – foram identificadas como itens de acompanhamento pelas equipes de suporte dos provedores envolvidos. ** Lessons learn ** O incidente destacou que falhas na camada de rede entre o CDN e a infraestrutura de nuvem são invisíveis ao monitoramento padrão de aplicativos, criando um ponto cego significativo. Como itens de acompanhamento, a equipe identificou a necessidade de implementar as correções de configuração recomendadas pelos provedores e expandir a observabilidade na camada de entrega de ativos para detectar proativamente esse tipo de degradação.

Traduzido automaticamente da atualização oficial do incidente.

1. 21 Gouere 2026 da 14:39 UTCidentified

   Caro cliente, Estamos investigando uma instabilidade em nossas capacidades do IDCloud, afetando os fluxos de criação e detalhes do processo. Nossa equipe de engenharia é mobilizada para resolver o problema o mais rápido possível. Vamos fornecer novas atualizações em breve.

2. 21 Gouere 2026 da 14:46 UTCidentified

   Continuamos trabalhando em uma solução para esse problema.

3. 21 Gouere 2026 da 14:50 UTCmonitoring

   Caro Cliente, Nossa equipe de engenharia identificou e implementou as ações necessárias para resolver a instabilidade nas capacidades de fluxo do IDCloud afetadas. Neste momento, a equipe técnica está realizando uma análise detalhada da nossa camada de dados e continua a monitorar o ambiente. Reiteramos que novas atualizações serão enviadas em breve.

4. 21 Gouere 2026 da 16:00 UTCresolved

   Resumo Executivo e Impacto Em 21 de julho de 2026, por volta das 11:17 AM BRT, uma queda de disponibilidade foi detectada no IDCloud criar-processo e processos-peritagem fluxos. Durante a janela de impacto, uma parcela dos clientes experimentou latências e falhas elevadas (tempo limite) nessas operações, que se propagaram através da cadeia de serviços dependentes. O impacto efetivo foi concentrado em uma janela de aproximadamente 23 minutos. No pico, os indicadores de erro e latência estavam acima dos níveis operacionais normais. Causa raiz e resolução A investigação apontou para a degradação de uma base de dados lida (replica) que apoia essas capacidades como origem. Este banco de dados começou a mostrar o aumento do tempo de execução de carga e consulta, com contenção interna que parou o processamento e fez backup das solicitações de leitura. Como resultado, os serviços acima começaram a acumular períodos de espera e a desencadear mecanismos de proteção (disjuntores de circuito), produzindo o efeito Cascading experimentado pelos clientes. Compromisso e Próximos Passos A Unico está lidando com este incidente com uma autópsia detalhada, já sendo elaborada, e realizará uma reunião de revisão pós-incidente (PiR) para consolidar ações preventivas. Dentre os acompanhamentos já levantados durante a resposta estão a elaboração de rotinas diagnósticas e consultas para acelerar a identificação de contencioso nessa camada de banco de dados, e melhoria da observabilidade sobre as bases de dados envolvidas. As ações preventivas detalhadas serão compartilhadas na autópsia. Reafirmamos nosso compromisso com a estabilidade e confiabilidade da plataforma e pedimos desculpas pelo inconveniente causado durante o período de instabilidade. Equipa Unico.

5. 28 Gouere 2026 da 12:10 UTCpostmortem

   **Resumo** Em 21 de julho de 2026, entre 11:41 e 11:43 \(Brasília time\), o fluxo de criação do processo tornou-se indisponível, com a principal taxa de erro de serviço atingindo 42% e latência de p99 em 15,75 segundos. O incidente foi causado pela saturação no banco de dados de biometria lido réplica: o banco de dados memory pool não foi mais capaz de atender o conjunto de dados mais frequentemente acessado, fazendo com que consultas normalmente rápidas caíssem para trás para leituras de disco, criando uma espiral auto-reforçante de sessões acumuladas e aumentando a latência. **Impacto Os usuários do processo de criação, autenticação e pagamentos fluem entre vários clientes que receberam erros e timeouts durante o período. A base de dados primária permaneceu intacta durante todo o incidente — a falha foi isolada da réplica lida. **Root Cause** A causa raiz foi a saturação: as consultas utilizadas no fluxo de autenticação estavam realizando extensas varreduras em tabelas críticas devido à falta de índices. Em condições normais, esse comportamento foi tolerado pela infraestrutura do banco de dados. Quando a capacidade de memória atingiu seu limite e não pôde mais manter os dados mais acessados em cache, cada leitura começou a buscar dados do disco, tornando o custo de cada consulta exponencialmente maior. Este efeito de colapso abrupto — onde a degradação gradual dá lugar a um fracasso generalizado — tornou-se auto-reforço à medida que as sessões acumuladas à espera de respostas e a contenção interna dos recursos da base de dados aumentou. Além disso, todo o tráfego de leitura para o fluxo crítico foi concentrado em uma única réplica, sem distribuição ou rota alternativa, eliminando qualquer resiliência a esse tipo de degradação. **Resolução** O banco de dados se recuperou naturalmente à medida que as sessões acumuladas se esgotavam, sem necessidade de intervenção manual. A equipe escalou para a equipe de banco de dados e monitorou a estabilização do serviço. O incidente foi encerrado após a confirmação de que a operação normal havia sido restaurada. ** Lessons learn ** O incidente revelou lacunas estruturais na camada do banco de dados: falta de índices em consultas críticas e concentração de todo o tráfego lido em uma única réplica sem rota alternativa. Como acompanhamentos, a equipe priorizou a criação dos índices faltantes, distribuição de tráfego de leitura através de réplicas, e construção de runbooks diagnósticos para acelerar a resposta em futuros incidentes de natureza semelhante.

Traduzido automaticamente da atualização oficial do incidente.

1. 20 Gouere 2026 da 12:33 UTCidentified

   Caro Cliente, Identificamos uma instabilidade em algumas de nossas capacidades do IDCloud, afetando o fluxo GetSelfie, criação de processos e detalhes do processo para a Jornada Web (anteriormente ByUnico). Os fluxos da API Journey (ByClient) não foram afetados. Nossa equipe de engenharia é mobilizada para resolver o problema o mais rápido possível. Seguiremos em breve com novas atualizações.

2. 20 Gouere 2026 da 12:35 UTCidentified

   Continuamos trabalhando em uma solução para esse problema.

3. 20 Gouere 2026 da 12:39 UTCmonitoring

   Caro Cliente, Nossa equipe de engenharia identificou e implementou as ações necessárias para resolver a instabilidade nas capacidades de fluxo do IDCloud afetadas. Neste momento, a equipe técnica está realizando uma análise detalhada da nossa camada de dados e continua a monitorar o ambiente. Reiteramos que novas atualizações serão enviadas em breve.

4. 20 Gouere 2026 da 13:22 UTCresolved

   Resumo Executivo e Impacto Identificamos uma instabilidade que afeta os fluxos de captura e visualização do processo, bem como autenticação, para a Web Journey, com impacto entre 09:07 e 09:21 (BRT). O impacto atingiu uma parte dos clientes usando este fluxo; a API Journey não foi afetada. Causa raiz e resolução A causa raiz está ligada a uma mudança de configuração aplicada na produção, que causou aumento da carga em um componente de banco de dados interno. Essa carga aumentada aumentou a latência e os erros em uma camada de integração, que por sua vez desencadeou um mecanismo de proteção e interrompeu temporariamente os fluxos da Web Journey. A equipe de engenharia retrocedeu a mudança de configuração para mitigar o problema, e a situação normalizou pouco depois. Compromisso e Próximos Passos A equipe de engenharia continua a monitorar o ambiente após o retorno das mudanças feitas. Uma autópsia detalhada será partilhada pela nossa equipa nos próximos dias. Pedimos desculpa pelo inconveniente. Equipa Unico!

5. 4 Eost 2026 da 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.

Traduzido automaticamente da atualização oficial do incidente.

1. 16 Gouere 2026 da 14:02 UTCinvestigating

   Caro Cliente, Estamos investigando uma instabilidade em nosso sistema de autenticação para os portais do Povo Unico e também estamos avaliando problemas em nosso serviço de mensagens que afetam clientes do IDCloud. Nossa equipe de engenharia é mobilizada para resolver o problema o mais rápido possível. Vamos fornecer actualizações em breve.

2. 16 Gouere 2026 da 14:08 UTCmonitoring

   Caro Cliente, A nossa equipa identificou a questão e tomou medidas para resolver o incidente. Nós experimentamos uma instabilidade no nosso sistema de autenticação para os portais Unico People, bem como problemas no nosso serviço de mensagens que afetam os clientes no fluxo IDCloud, para SMS e entrega de email. Nossa equipe de engenharia continua mobilizada, monitorando o ambiente para garantir que ele continue funcionando corretamente.

3. 16 Gouere 2026 da 15:28 UTCresolved

   Resumo Executivo e Impacto Às 10:51 da manhã de 16/07/2026, foi identificado um problema no serviço de autenticação no portal de admissão do Unico People e nas mensagens, que afetou a entrega de SMS e links de e-mail aos clientes do Unico People e IDCloud, bem como a autenticação do cliente B2C no portal de admissão do Unico People. O impacto foi limitado a estes dois fluxos e não afetou a jornada crítica principal do produto. O incidente durou aproximadamente 30 minutos até a resolução completa. Causa raiz e resolução A causa raiz foi identificada como pressão de armazenamento em um nó do cluster de mensagens, que atingiu um limiar crítico de disco, degradando o processamento das filas responsáveis pela entrega de mensagens e autenticação. A equipe de engenharia aumentou a capacidade de armazenamento do cluster em aproximadamente 10:59 AM, o que permitiu que filas e indicadores de monitoramento normalizassem em minutos. O ambiente foi monitorado até a confirmação da recuperação completa e o incidente foi encerrado às 11:20h. Compromisso e Próximos Passos A equipe de engenharia revisará os critérios de alerta de escalada e priorização para esse tipo de degradação, uma vez que os alertas identificaram corretamente o problema, mas o fluxo automático de escalada para a equipe responsável pode ser melhorado. Uma autópsia detalhada está a ser preparada e será partilhada nos próximos dias.

4. 3 Eost 2026 da 12:14 UTCpostmortem

   **Resumo** Em 16 de julho de 2026, entre 10:12 e 11:10 \(Tempo brasília\), o serviço de mensagens e autenticação foi degradado por aproximadamente 58 minutos. A causa foi saturação de disco em um dos nós no cluster de fila de mensagens, que, ao atingir o limite configurado, bloqueou automaticamente todos os editores, causando um atraso de até 33 mil mensagens na fila. O impacto afetou a entrega de links de autenticação via SMS e e-mail, bem como o fluxo de autenticação do usuário final no portal de admissão do Unico People. **Impacto Usuários aguardando links de autenticação via SMS ou e-mail não os receberam durante o período. Os utilizadores finais de um produto de gestão de pessoas que tentavam autenticar-se no portal de admissão também não conseguiram aceder ao serviço. O impacto foi contido após a expansão do disco do cluster. **Root Cause** A causa raiz foi identificada no fluxo de processamento de mensagens: cargas excessivamente grandes – geradas por um componente de auditoria que incluía dados desnecessários – excederam o limite de tamanho aceito pelo cluster de fila de mensagens. Como eles foram deterministicamente rejeitados em cada tentativa, essas mensagens foram encaminhadas para filas de letras mortas após esgotar todas as repetições. Essas filas não tinham nenhuma política de expiração ou limpeza automática, fazendo com que as mensagens se acumulassem indefinidamente e progressivamente consumissem o espaço em disco do cluster. **Resolução** O disco do cluster foi expandido para 500 GB por nó, que imediatamente normalizou as filas e as métricas do cluster. O serviço voltou ao normal às 11:10. A causa raiz estrutural — o acúmulo indefinido nas filas de letras mortas — permanece como um item de seguimento a ser abordado. ** Lessons learn ** O incidente reforça que abordar apenas o sintoma \(saturação do disco\) sem investigar a causa raiz do acúmulo garante a recorrência do problema. A ausência de uma política de ciclo de vida \(TTL/expiration\) para filas de letras mortas e a falta de validação do tamanho da carga útil antes da publicação são as duas lacunas estruturais centrais a serem corrigidas. Além disso, o alerta que sinalizava a questão foi classificado como baixa prioridade, o que causou um atraso de aproximadamente 38 minutos entre o alerta sendo disparado e a abertura formal do incidente – um intervalo inaceitável para uma degradação crítica do serviço.

Traduzido automaticamente da atualização oficial do incidente.

1. 13 Gouere 2026 da 12:51 UTCidentified

   Caro Cliente, Identificamos uma instabilidade na capacidade de verificação de identidade, gerando um erro em uma pequena parcela das solicitações do IDCloud. Nossa equipe de engenharia já está mobilizada para diagnóstico e trabalho para identificar a causa raiz, a fim de normalizar o serviço o mais rapidamente possível. Neste momento, a equipe técnica está realizando análises detalhadas em nossa camada de dados para mitigar o impacto. Reforçamos que novas atualizações serão enviadas em breve.

2. 13 Gouere 2026 da 13:06 UTCmonitoring

   Caro Cliente, Nossa equipe de engenharia identificou e implementou as ações para resolver a instabilidade na capacidade de verificação de identidade que estava gerando um erro em uma pequena parcela das solicitações do IDCloud. Neste momento, a equipe técnica está realizando análises detalhadas em nossa camada de dados e continua monitorando o ambiente. Reforçamos que novas atualizações serão enviadas em breve.

3. 13 Gouere 2026 da 13:47 UTCresolved

   Resumo Executivo e Impacto Em 13 de julho de 2026, identificamos uma instabilidade em nossa capacidade de verificação de identidade, gerando erros em uma parcela mínima de solicitações do IDCloud, afetando múltiplos fluxos de autenticação. O problema foi detectado por meio de alertas de disponibilidade automatizados por volta das 9:27 AM BRT, com um ligeiro aumento de erros já perceptível a partir de aproximadamente 8:00 AM BRT e um agravamento significativo a partir das 9:07 AM BRT, atingindo o pico de impacto por volta das 9:49 AM BRT. Causa raiz e resolução A causa raiz foi identificada como uma mudança gradual aplicada a um componente de autenticação interna, que causou uma falha na validação da assinatura do token de sessão. Uma vez confirmada a causa raiz, a equipe de engenharia reverteu a mudança, e a disponibilidade de serviço voltou ao normal. A fase mais crítica do impacto durou aproximadamente 44 minutos. Compromisso e Próximos Passos A engenharia está avaliando melhorias no processo de validação de mudanças para lançamentos graduais que afetam componentes críticos de autenticação, incluindo mecanismos de retrocesso automáticos em caso de picos de erro durante este tipo de implantação. Espera-se que uma autópsia detalhada seja partilhada internamente como próximo passo.

4. 20 Gouere 2026 da 22:47 UTCpostmortem

   # Postmortem: Autenticação Instabilidade do Fluxo ** Data de ocorrência:** 13 de julho de 2026 ** Duração do impacto:** ~44 minutos # # Resumo Em 13 de julho de 2026, identificamos uma degradação da disponibilidade nos fluxos de autenticação da plataforma. O incidente foi causado por uma incompatibilidade introduzida durante uma implantação contínua de um componente interno responsável pela validação de fichas de segurança. A causa foi diagnosticada pelas nossas equipes de operações, e a atualização restabeleceu a estabilidade do sistema em poucos minutos. # # Impacto A degradação durou aproximadamente 44 minutos e afetou simultaneamente múltiplos fluxos de autenticação na plataforma, resultando em uma taxa de erro de aproximadamente 0,9% nos serviços voltados para o cliente. Durante esse período, alguns usuários finais experimentaram instabilidade e viram mensagens de erro genéricas \(HTTP 500\) ao tentar autenticar. Embora o evento tenha durado 44 minutos, variou entre o aumento da latência e a indisponibilidade. # # Causa raiz A falha foi causada por um defeito de software introduzido em uma atualização para o componente de validação de token de segurança, resultando em incompatibilidade entre instâncias executando diferentes versões. Essa incompatibilidade não foi detectada em ambientes de teste, pois exigia a execução simultânea e paralela de diferentes versões. Além disso, o endpoint interno retornou uma resposta de sucesso HTTP mesmo quando a validação falhou, o que impediu que os sistemas de monitoramento automatizado de implantação detectassem o problema e parassem automaticamente o lançamento. # # Resolução Uma vez identificada a causa, a equipe de plantão executou um retorno do componente afetado, restaurando imediatamente a disponibilidade dos fluxos de autenticação. O incidente foi detectado por alertas de SLO automatizados minutos após o início da degradação, e a escalada possibilitou o diagnóstico completo e a mitigação do incidente. # # Lições aprendidas Vamos melhorar a validação de compatibilidade de versão em implantações de rolamento, ajustar o comportamento de resposta HTTP de endpoints internos para desencadear o rollback automático de implantações falhando, e padronizar o manuseio de erros para evitar falhas de serem mascaradas antes de atingir o cliente. # # Compromisso com a melhoria contínua Incidentes como este reforçam nosso compromisso de melhorar continuamente a confiabilidade da plataforma. Tratamos cada incidente como uma oportunidade de aprendizagem, revisando nossos processos, fortalecendo mecanismos de detecção e prevenção e investindo continuamente em práticas de engenharia mais robustas. Nosso objetivo é continuar aumentando a margem de disponibilidade e transparência para todos os nossos clientes. Equipa Unico.

Traduzido automaticamente da atualização oficial do incidente.

1. 10 Gouere 2026 da 16:43 UTCinvestigating

   Atualmente estamos experimentando instabilidade nas capacidades do IDCLOUD. A nossa equipa técnica já está a investigar a causa principal. Forneceremos atualizações assim que mais informações estiverem disponíveis.

2. 10 Gouere 2026 da 17:12 UTCidentified

   Identificamos uma instabilidade que pode causar tempo de parada temporária ou latência em algumas de nossas APIs de verificação e análise de risco. Serviços afetados: - Identidade & Validação: Verificação de Identidade, Validação 1:1, Retorno de Semelhança Serpro - Risco & Fraude: Pontuação de risco, Classificação de risco de fraude - Documentação e Vida: Reutilização e Captura de Documentos, Vida Status atual e próximos passos: Nossa equipe de engenharia já está totalmente envolvida e investigando a causa raiz. Estamos trabalhando ativamente para isolar o comportamento e restaurar operações normais o mais rápido possível.

3. 10 Gouere 2026 da 17:25 UTCmonitoring

   Estado atual e próximos passos As ações de atenuação foram aplicadas com sucesso, e o sistema está agora estável. Neste momento, nossa equipe de Engenharia continua monitorando ativamente o desempenho da plataforma para garantir a estabilidade contínua e operações normais. Obrigado pela sua paciência e compreensão durante este incidente. Os seus serviços devem agora funcionar normalmente.

4. 10 Gouere 2026 da 17:57 UTCresolved

   Resumo Executivo e Impacto Entre as 13h21 e as 14h16 (hora Brasília) de 10 de julho de 2026, identificamos uma flutuação na disponibilidade do fluxo de criação de processos e viagens relacionadas, resultando em um pico temporário na taxa de erro de algumas de nossas principais APIs. - Escopo do Impacto: O evento afetou exclusivamente a disponibilidade de determinadas viagens durante este intervalo. Os clientes que não experimentaram um aumento em sua taxa de erro durante esse período não foram impactados. - Integridade dos Dados: Não houve compromisso com a integridade ou segurança das informações processadas. - Mitigação: Uma solução inicial foi aplicada em poucos minutos, parando o volume de erros. O serviço foi totalmente normalizado às 2:16 horas, após confirmação de estabilidade de nossas equipes de Engenharia e Monitoramento. Causa raiz O incidente foi desencadeado pela instabilidade em um serviço de infraestrutura, seguido por uma súbita degradação na inicialização de componentes internos relacionados. Compromisso e Próximos Passos Estamos profundamente comprometidos com a resiliência de nossa plataforma. As ações corretivas e preventivas iniciadas durante o incidente já estão sendo monitoradas para mitigar o risco de ocorrências futuras dessa natureza. - Postmortem: Um relatório técnico detalhado (Postmortem) será compartilhado em breve, contendo a linha do tempo completa, análise arquitetônica, e um plano de ação de longo prazo com prazos definidos. Pedimos sinceras desculpas pelo impacto e instabilidade causados. A confiança dos nossos clientes é a nossa maior prioridade e continuamos a trabalhar continuamente para garantir a excelência dos nossos serviços. Atenciosamente, Unico Team

5. 14 Gouere 2026 da 14:08 UTCpostmortem

   **Resumo** Em 10 de julho de 2026, entre 1:21 PM e 2:09 PM \(Brasília time\), a taxa de erro no fluxo de criação do processo atingiu um pico de aproximadamente 11% por cerca de 9 minutos, com contínua degradação da disponibilidade até 2:09 PM. O incidente foi causado por uma instabilidade no componente de gerenciamento da configuração da infraestrutura, o que impediu que as cápsulas de serviço de biometria inicializassem corretamente. O impacto foi amplificado por um comportamento pré-existente de consumo de memória \(que aumentou a frequência de reinicialização do pod\) e por um pico de tráfego que desencadeou a criação de novas instâncias – todas as quais foram incapazes de inicializar durante a janela de instabilidade do componente de configuração. □ **Impacto Vários fluxos foram afetados simultaneamente — incluindo a criação de processos, autenticação, biometria, pagamentos e operações internas — com erros propagando-se em todos os serviços dependentes do motor biométrico. No seu pico, a taxa de erro atingiu 11%. O número de cápsulas de serviço de biometria disponíveis caiu para quase zero em ambos os clusters de produção durante a janela mais crítica do incidente. □ **Root Cause** A causa raiz foi relacionada a uma oportunidade de otimização na lógica de inicialização do serviço de biometria: a aplicação recusou-se a aparecer se o componente de gerenciamento de configuração de infraestrutura retornasse uma falha durante o boot, mesmo quando os dados em cache estavam disponíveis para uso como backback. Essa lógica tratou uma falha de comunicação transitória da mesma forma que um erro de configuração permanente, tornando o cache de retorno inutilizável exatamente no momento em que era mais necessário. Quando o componente de configuração se tornou instável, cada módulo que tentava reiniciar — seja devido à pressão de memória ou ao auto-escalamento — ficou preso em um loop de falha, incapaz de completar o processo de inicialização. □ **Resolução** A equipe continha o impacto inicial isolando o tráfego de um dos componentes afetados, o que parou o pico de erro em aproximadamente 9 minutos. Seguiu-se a estabilização do componente de gerenciamento de configuração, permitindo que os pods retornassem normalmente. Uma correção de emergência foi preparada e implantada no mesmo dia, removendo a validação restritiva que bloqueou a inicialização — garantindo que o cache de retorno seja usado de forma transparente em situações semelhantes. ** Lessons learn ** O incidente revelou que o mecanismo de resiliência do serviço — o cache de retorno — existia na arquitetura, mas foi neutralizado pela lógica de inicialização, que priorizou a validação de dados estrita sobre a disponibilidade do ambiente. Os caminhos de arranque dos serviços críticos devem ser concebidos para se degradarem graciosamente quando os componentes de infra-estrutura de apoio são instáveis, garantindo a continuidade operacional. ** Compromisso com estabilidade e melhoria contínua ** Continuaremos a investir fortemente na robustez de nossa infraestrutura para garantir que nossos serviços funcionem de forma consistente nos mais altos níveis de eficiência, segurança e confiabilidade. Equipa Unico.

Traduzido automaticamente da atualização oficial do incidente.

1. 7 Gouere 2026 da 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 Gouere 2026 da 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 Gouere 2026 da 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 Gouere 2026 da 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 Gouere 2026 da 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 Gouere 2026 da 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 Gouere 2026 da 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 Gouere 2026 da 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 Gouere 2026 da 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 Gouere 2026 da 22:05 UTCidentified

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

3. 3 Gouere 2026 da 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 Gouere 2026 da 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 Gouere 2026 da 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 Mezheven 2026 da 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 Gouere 2026 da 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 Mezheven 2026 da 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 Mezheven 2026 da 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 Mezheven 2026 da 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 Gouere 2026 da 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 Mezheven 2026 da 01:24 UTCinvestigating

   Prezado Cliente, Nossa monitoração proativa detectou um comportamento irregular no ID Pay e no fluxo de onboarding do ByUnico. Embora a causa exata ainda está sob investigação, então pode se manifestar como lentidão ou interferência no serviço. A equipa de tecnologia está a executar todos os procedimentos de diagnóstico no ambiente para identificar as causas. Em breve retornamos com actualizações.

2. 23 Mezheven 2026 da 01:39 UTCidentified

   Prezado Cliente, Nossa equipe ainda está investigado a causa raiz do problema. Em breve traremos mais actualizações. Agradecemos a compreensão.

3. 23 Mezheven 2026 da 01:53 UTCidentified

   Prezado Cliente, Informação que nossa equipe identificou a causa da instabilidade e está ativando trabalho na aplicação da solução. Seguimos empenhados em restabelecer o serviço o mais rápido possível e manteremo-nos informado sobre a evolução. Novas avaliações serão enviadas em breve.

4. 23 Mezheven 2026 da 02:18 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 mais detalhes de um postmortem. Pedimos desculpas pelo transtorno e nos colamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenção, Equipa Unico!

5. 23 Mezheven 2026 da 02:41 UTCresolved

   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 mais detalhes de um postmortem. Pedimos desculpas pelo transtorno e nos colamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenção, Equipa Unico!

6. 14 Gouere 2026 da 13:58 UTCpostmortem

   **Resumo** Em 22 de junho de 2026, às 9:52 PM \(Brasília time\), o fluxo de economia de documentos tornou-se indisponível devido à exaustão de um limite identificador sequencial no banco de dados. A partir desse momento, todas as operações de inserção de documentos passaram a falhar, errando para múltiplos serviços dependentes. O incidente durou aproximadamente 86 minutos. □ **Impacto Vários serviços críticos foram afetados simultaneamente — incluindo fluxos de onboarding, criação de processos, autenticação e pagamentos. Em alguns fluxos, a disponibilidade caiu para abaixo de 3%. Os clientes tiveram os usuários impactados por falhas ou atrasos ao tentar operações que dependiam da gravação de documentos. □ **Root Cause** A causa raiz foi relacionada ao tipo de identificador de 32 bits utilizado na tabela de documentos, que suporta aproximadamente 2,1 bilhões de valores; com o crescimento natural do volume de registro ao longo do tempo, esse limite foi alcançado, fazendo com que o banco de dados não pudesse mais gerar novos identificadores, de modo que todas as operações de inserção começaram a falhar. Como não houve monitoramento configurado para rastrear a proximidade desse limite, o esgotamento ocorreu abruptamente e sem aviso prévio. □ **Resolução** A equipe identificou a causa raiz em aproximadamente 20 minutos. Como mitigação imediata, o identificador sequencial foi reconfigurado para utilizar a faixa negativa do mesmo tipo de dados, libertando-se aproximadamente mais 2,1 bilhões de valores sem exigir qualquer alteração estrutural no banco de dados. A solução foi validada em ambientes inferiores antes de ser aplicada à produção. O serviço começou a estabilizar logo após a aplicação da correção e foi monitorado até a confirmação da recuperação completa. □ ** Lessons learn ** O incidente destaca a importância de implementar o monitoramento para o uso do identificador sequencial em tabelas de alto volume, com alertas precoces que permitam o manejo da exaustão como manutenção planejada; adotar os tipos de identificadores de 8 bytes desde o início para tabelas com alto volume de gravação, incluindo essa verificação em processos de revisão de esquemas; e mapear e documentar as dependências críticas dos serviços de persistência centrais, a fim de dimensionar o impacto e priorizar a comunicação com usuários afetados mais rapidamente em incidentes futuros.

Traduzido automaticamente da atualização oficial do incidente.

1. 19 Mezheven 2026 da 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 Mezheven 2026 da 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 Mezheven 2026 da 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 Gouere 2026 da 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 Mezheven 2026 da 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 Mezheven 2026 da 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 Mezheven 2026 da 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 Mezheven 2026 da 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 Mezheven 2026 da 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 Mezheven 2026 da 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 Mezheven 2026 da 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