Affected components
Update timeline
- identified Mar 12, 2026, 12:27 PM UTC
Prezado Cliente, Identificamos uma instabilidade que afeta a capacidade de Prova de Vida (Liveness) em nossos serviços. Nossa equipe de engenharia já está mobilizada e trabalhando intensamente no diagnóstico para restabelecer a normalidade o mais breve possível. Entendemos a importância dessa funcionalidade para sua operação e priorizamos a resolução deste cenário. Reforçamos nosso compromisso com a transparência e enviaremos novas atualizações assim que tivermos mais informações sobre a evolução do reparo. Atenciosamente, Equipe Unico.
- identified Mar 12, 2026, 12:53 PM UTC
Prezado Cliente Nossa equipe de tecnologia segue atuando proativamente para identificar a causa raiz e restabelecer a normalidade do serviço de Prova de Vida. Manteremos todos informados com novas atualizações sobre o progresso e a resolução do incidente em breve. Agradecemos a sua compreensão e paciência.
- monitoring Mar 12, 2026, 01:28 PM UTC
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!
- resolved Mar 12, 2026, 02:45 PM UTC
Prezado Cliente, Informamos que a instabilidade que afetou a disponibilidade da capacidade de Prova de Vida (Liveness) foi totalmente resolvida. Resumo Executivo e Impacto No dia de hoje, identificamos uma instabilidade temporária em nosso serviço de captura de dados biométricos entre 09:07 e 09:20. Durante este intervalo, uma parcela dos usuários enfrentou dificuldades ao tentar realizar autenticações e capturas, resultando em uma queda na taxa de disponibilidade. Lamentamos o ocorrido e ressaltamos que o restabelecimento da normalidade foi priorizado para minimizar o impacto na experiência dos usuários finais e na operação de nossos clientes parceiros. Causa Raiz e Resolução A instabilidade foi originada por uma falha ainda sob investigação que afetou a infraestrutura de nuvem. O comportamento observado é consistente com um incidente anterior registrado junto ao provedor. A equipe de engenharia interveio e o serviço foi totalmente restabelecido às 09:20, operando com estabilidade desde então. A investigação junto ao fornecedor segue em andamento. Um Postmortem detalhado será elaborado e compartilhado em breve, detalhando as melhorias estruturais de longo prazo. Lamentamos o impacto causado em sua operação e permanecemos à disposição. Atenciosamente, Equipe Unico.
- postmortem Mar 24, 2026, 08:49 PM UTC
# Postmortem: Incidente de Disponibilidade na Plataforma de Biometria e Liveness ## Resumo Em 12 de março de 2026, nossa plataforma de captura de dados e biometria enfrentou uma degradação significativa de serviço. O incidente foi desencadeado por um pico repentino de tráfego que sobrecarregou o servidor de modelos de _liveness_, levando a um aumento drástico na latência e a uma queda acentuada na disponibilidade para o processamento de inferências. ## Impacto Entre **09:10 e 09:22 \(BRT\)**, a disponibilidade para os fluxos de biometria e _liveness_ caiu para níveis próximos a **1%**, afetando todos os clientes que utilizavam esses serviços no período. O sistema apresentou lentidão extrema e erros de tempo de resposta \(_timeout_\), impactando a experiência do usuário final. A estabilidade total das métricas foi confirmada às 17:31, após a implementação de ajustes estruturais. ## Causa Raiz A investigação identificou uma falha de design na forma como o sistema lidava com saturação de carga. O incidente seguiu a seguinte progressão: 1. **Pico de Requisições:** Um aumento inesperado no volume de tráfego proveniente de setores específicos sobrecarregou o servidor de modelos. 2. **Degradação Silenciosa:** A aplicação de inferência aceitou mais conexões simultâneas do que sua capacidade de processamento permitia. Em vez de rejeitar o excesso de carga com erros rápidos, o sistema tentou processar todas as requisições, o que causou uma disputa de recursos de CPU. Isso elevou o tempo de resposta de 2 segundos para mais de 30 segundos. 3. **Invisibilidade do Circuit Breaker:** Os mecanismos de proteção da rede não detectaram a falha, pois as desconexões dos clientes por lentidão e as respostas de limite de taxa \(_Rate Limit_\) foram interpretadas como eventos normais de rede, impedindo o isolamento automático dos componentes degradados. 4. **Efeito Cascata:** O tempo de inicialização de novos recursos para escala automática foi insuficiente para absorver o impacto imediato, sobrecarregando ainda mais as instâncias ativas. ## Resolução Para mitigar o problema e restaurar o serviço, foram tomadas as seguintes medidas: * **Ajuste de Configurações:** Revertemos alterações recentes nos limites de detecção de anomalias que se mostraram contraproducentes sob estresse. * **Gestão de Tráfego:** Implementamos novos limites locais de taxa de transferência e consolidamos as janelas de escalonamento para garantir que o sistema estivesse melhor preparado para picos de demanda. * **Estabilização:** As alterações foram implantadas via ferramentas de entrega contínua, e a estabilidade da latência foi confirmada após o deploy final às 17:31. ## Lições Aprendidas * **Falha por Lentidão vs. Falha por Erro:** Aprendemos que o sistema deve ser configurado para "falhar rápido" \(_fail fast_\). Aceitar requisições além da capacidade nominal causa degradação silenciosa, que é mais difícil de detectar e corrigir do que erros explícitos. * **Visibilidade do Mesh:** Identificamos a necessidade de tornar erros de limite de taxa \(429\) e desconexões de clientes visíveis para os mecanismos de auto-recuperação da malha de serviços. * **Backpressure:** A ausência de limites estritos de fila de conexões impediu a geração de pressão reversa \(_backpressure_\) necessária para proteger a integridade do sistema. Estamos comprometidos com a estabilidade de nossos ambientes e atuaremos nas ações preventivas, mitigando impactos similares no futuro. Agradecemos a compreensão e estamos à disposição para esclarecer quaisquer dúvidas. Atenciosamente, Equipe Unico.
Looking to track Unico downtime and outages?
Pingoru polls Unico's status page every 5 minutes and alerts you the moment it reports an issue — before your customers do.
- Real-time alerts when Unico reports an incident
- Email, Slack, Discord, Microsoft Teams, and webhook notifications
- Track Unico alongside 5,000+ providers in one dashboard
- Component-level filtering
- Notification groups + maintenance calendar
5 free monitors · No credit card required