Historial de interrupciones de Unico

1. August 30, 2026 at 2:35 AM UTCinvestigating

   Querido cliente, Aproximadamente las 11:00 PM (BRT) el viernes 29 de agosto de 2026, identificamos una inestabilidad que afecta la creación de procesos en IDCloud. Durante este período, algunas solicitudes pueden fallar o experimentar una experiencia más lenta de lo habitual. Reconocemos la inconveniencia que esto puede causar y apreciar su comprensión. En breve se proporcionará una nueva actualización. Unico Team

2. August 30, 2026 at 2:49 AM UTCidentified

   Nuestro equipo de ingeniería ha mapeado el origen de la inestabilidad que afecta la creación de procesos en IDCloud. El equipo técnico ya ha comenzado a aplicar medidas correctivas, incluidos recursos de escala en la capa afectada y a vigilar continuamente los indicadores clave. Restaurar el servicio está siendo manejado con máxima prioridad y movilización de ingeniería completa. Reiteramos que pronto se enviarán nuevas actualizaciones. Unico Team

3. August 30, 2026 at 2:57 AM UTCmonitoring

   Querido cliente, Nuestro equipo de ingeniería ha llevado a cabo las acciones correctivas necesarias para resolver la inestabilidad que afecta a la creación de procesos en IDCloud. El medio ambiente ha vuelto a la estabilidad, con indicadores de disponibilidad y tiempo de respuesta restaurados a los niveles operativos normales a las 11:48 PM (BRT). El servicio está disponible para uso normal. En este momento, nuestro equipo técnico sigue bajo vigilancia asistida, observando de cerca el medio ambiente para garantizar un desempeño coherente y actuar inmediatamente en caso de fluctuación. Agradecemos su comprensión y reiteramos que pronto se enviarán nuevas actualizaciones. Unico Team

4. August 30, 2026 at 3:15 AM UTCresolved

   Querido cliente, Resumen e impacto ejecutivo Entre las 11:00 PM y las 11:48 PM (BRT) el 29 de agosto de 2026, un outage afectó la creación de procesos en IDCloud. Durante esta ventana, algunos clientes que utilizan estos flujos experimentaron fallos y tiempos de respuesta mayores, con propagación a viajes dependientes incluyendo autenticación, captura de documentos y entrega de notificaciones. No hubo compromiso con la integridad o seguridad de la información procesada, y no se perdieron datos. Indicadores devueltos a niveles operativos normales a las 11:48 PM (BRT), con la normalización confirmada tanto en nuestro monitoreo como en el lado del cliente, cubriendo la creación del proceso y la terminación. Causa raíz y resolución El origen fue identificado en nuestra capa de datos: una rutina interna de mantenimiento se atascó, y las operaciones de aplicación comenzaron a colarse detrás de él hasta que se agotó el límite de conexión disponible, reduciendo la capacidad de procesamiento. Nuestro equipo de ingeniería terminó quirúrgicamente sólo la rutina atascada, liberando inmediatamente la cola. Se restablecieron plenamente las conexiones y la capacidad de procesamiento, sin cambios de datos. Compromiso y próximos pasos Nuestro equipo de ingeniería se centrará en tres frentes: limitar los tiempos de espera para las rutinas internas de mantenimiento, evitar que las rutinas concurrentes corran contra la misma estructura y fortalecer la resiliencia de los servicios a las fluctuaciones en la capa de datos. En breve se compartirá un calendario detallado, que incluye el calendario completo y un plan de acción con plazos. Sinceramente nos disculpamos por el impacto en sus operaciones y seguimos disponibles a través de nuestros canales de apoyo. Unico Team

Traducido automáticamente desde la actualización oficial del incidente.

1. August 10, 2026 at 8:26 PM UTCidentified

   Querido cliente, Hemos detectado un impacto en algunas solicitudes de IDCloud, afectando la capacidad de Alerta de Comportamiento (IDTrust) y el flujo 1:N. Esta inestabilidad también puede afectar a clientes en México que utilizan esta capacidad. Nuestro equipo de ingeniería se moviliza para resolver el problema lo antes posible. Vamos a proporcionar nuevas actualizaciones en breve.

2. August 10, 2026 at 8:29 PM UTCmonitoring

   Nuestro equipo de ingeniería ha identificado y aplicado las medidas necesarias para resolver la inestabilidad en las capacidades de flujo de IDCloud afectadas. En este momento, el equipo técnico está realizando un análisis detallado de nuestra capa de datos y sigue vigilando el medio ambiente. Reiteramos que pronto se enviarán nuevas actualizaciones.

3. August 10, 2026 at 9:01 PM UTCresolved

   Resumen e impacto ejecutivo Alrededor de las 5:08 PM, una alerta automatizada detectó una caída de disponibilidad en el servicio de reconocimiento facial (1:N flujo), desencadenando el incidente. El problema se agravó rápidamente y comenzó a afectar el servicio de alerta de comportamiento y, posteriormente, el flujo de creación de procesos, debido a los intervalos de tiempo entre estos servicios. El impacto afectó a un subconjunto de clientes utilizando estas capacidades. The situation was reported astabild at 5:22 PM, with métricas returning to normal levels. Causa raíz y resolución La causa raíz fue un aumento de tráfico generado por un volumen de trabajo interno, que envió un alto volumen de solicitudes de reconocimiento facial directamente en el oleoducto biométrico, superando la capa de borde utilizada por el tráfico normal del cliente. Este volumen adicional saturaba la capacidad de la base de datos que apoyaba el servicio de reconocimiento facial. La saturación causó timeouts en ese servicio, que encadenó al servicio de orquestación de motores biométricos, luego al servicio de alerta de comportamiento, y finalmente al flujo de creación de procesos utilizando estas capacidades. Para resolver el problema, el equipo detuvo la carga de trabajo responsable del aumento y aumentó la capacidad de la base de datos afectada. Estas acciones mitiguen el problema, con el volumen de error que regresa a niveles cercanos a cero. Compromiso y próximos pasos Se abrió un elemento de seguimiento para aplicar la limitación de la tasa del tipo de volumen de trabajo interno que causó el pico, como medida preventiva contra la recurrencia. El aumento de la capacidad de la base de datos afectada ya se realizó durante el incidente mismo.

4. August 25, 2026 at 1:05 PM UTCpostmortem

   **Summary** El 10 de agosto de 2026, entre las 5:08 PM y las 5:27 PM \(Brasília time\), el indicador de disponibilidad para el flujo de reconocimiento facial 1:N cayó por debajo del 95%, con un impacto total de aproximadamente 19 minutos. El incidente fue causado por la saturación de la base de datos de búsqueda vectorial utilizada por el motor biométrico, resultante de comportamiento inesperado en el mecanismo de consumo de cola, que generó un volumen de llamada 2.36 veces mayor que configurado. El exceso de carga alcanzó el límite máximo de escalado de la base de datos, causando un tiempo de caducidad en varios servicios dependientes y afectando a 55 usuarios de clientes con errores durante el período. # Impact** Los usuarios del reconocimiento facial, autenticación y creación de procesos fluyen de múltiples clientes experimentaron errores y timeouts durante el período. La saturación de la base de datos encadenó a través de los servicios de orquestación biométrica, motor y creación de procesos. Mitigation was carried out by disabling an internal service and increasing the database's maximum scaling limit, stabilizing the service at 5:27 PM. *Causa real* La causa raíz fue una combinación de factores relacionados con el comportamiento del servicio y la capacidad de la infraestructura implicada. El servicio fue configurado con un límite de 2 solicitudes por segundo, pero el mecanismo de consumo de cola se comportó inesperadamente: mensajes cuyo procesamiento superó el plazo de reconocimiento fueron entregados por la cola sin cancelar la ejecución original, convirtiendo 938 artículos de trabajo en 2.217 llamadas efectivas \(~8.4 RPS\). Este tráfico amplificado alcanzó la base de datos sin pasar por la capa de protección de bordes, que normalmente limitaría el volumen de solicitud, ya que la ruta de red utilizada en este flujo no pasaba por esos controles. La base de datos, ya operando cerca de su límite máximo de escalado, no pudo absorber la carga adicional — su CPU alcanzó el 88% al escalar hasta el techo configurado de 100 nodos — y la latencia de consultas saltó de ~3 segundos a ~18.75 segundos a p90, propagando los plazos a través de toda la cadena de servicios dependientes. **Resolución** El equipo identificó el proceso en cuestión como la fuente de la carga en unos minutos de la alerta. El proceso fue desactivado, y el límite máximo de escalado de la base de datos se incrementó de 100 a 150 nodos. Con estas dos acciones, el servicio se estabilizó a las 5:27 PM. **Las razones aprendidas** El incidente mostró que la limitación de tarifas aplicada sólo en el lado de publicación de mensajes es insuficiente cuando el consumidor puede amplificar el volumen a través de la entrega. Los controles de tasa y concurrencia también deben existir en el lado del consumo. Además, los servicios internos que acceden a componentes críticos a través de caminos que evitan las protecciones de bordes representan un riesgo estructural: cualquier cliente interno puede generar carga incontrolada en infraestructura compartida.

Traducido automáticamente desde la actualización oficial del incidente.

1. July 31, 2026 at 12:42 PM 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 destinatários continuam recebendo e conseguindo assinar os arquivos. No 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. July 31, 2026 at 1:08 PM 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 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. July 31, 2026 at 1:20 PM UTCmonitoring

   Prezados clientes, Informamos que a correção para a exibição no painel de acompanhamento foi aplicada com sucesso. Una 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. July 31, 2026 at 2:06 PM UTCresolved

   Prezados clientes, Informamos que o incidente relacionado à exibição de envios no painel de acompanhamento foi oficialmente encerrado. Após a 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,

Traducido automáticamente desde la actualización oficial del incidente.

1. July 29, 2026 at 2:04 PM UTCresolved

   Resumen Ejecutivo " Impacto " Nos gustaría informarle de que el incidente que afecta temporalmente al servicio de notificación de ID Cloud Webhook se ha resuelto. Período de impacto: De 08:32 a 10:05. Impacto de la plataforma: La inestabilidad se limitó estrictamente a la notificación de Webhook, lo que dio lugar a un retraso en la distribución de mensajes. No hubo degradación de la plataforma principal, ni fallas en el motor de la vida, ni pérdida de datos. Impacto del cliente: El problema afectó una pequeña parte de los clientes. Los clientes que han implementado un flujo de votación de GET como contingencia (fallback) no experimentaron inactividad o impacto operativo. Causa raíz de la resolución Causa raíz: La inestabilidad fue desencadenada por una actualización de características en el medio ambiente. Un desajuste temporal de los permisos de acceso entre la cola de tareas y la ruta de destino causó la denegación de solicitudes, lo que dio lugar a un atraso temporal de notificaciones. Resolutive Action: El equipo técnico completó la redirección de tráfico al nuevo entorno, restaurando la comunicación adecuada entre los componentes y liberando el atraso de Webhooks. El procesamiento ha vuelto a la normalidad, y la cola de despacho ha sido completamente limpiada. Compromiso " Siguientes pasos La estabilidad de nuestros servicios es nuestra máxima prioridad. Para garantizar la transparencia total y evitar la recurrencia, nuestro equipo de ingeniería se centrará en los siguientes frentes: Postmortem detallado: Se preparará un informe amplio con un análisis profundo de las causas profundas y un plan de acción preventiva. Mejoras de la observabilidad: Ajustaremos las métricas de vigilancia para asegurar una mayor visibilidad en los errores de comunicación entre los servicios durante los escenarios de transición. Sinceramente nos disculpamos por la inconveniencia y seguimos disponibles para cualquier aclaración adicional. Sinceramente, Unico Team

2. August 7, 2026 at 1:08 PM 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.

Traducido automáticamente desde la actualización oficial del incidente.

1. July 24, 2026 at 9:47 PM UTCinvestigating

   Querido cliente, Actualmente estamos investigando una inestabilidad en nuestros Webhooks que está afectando latencia en la entrega de datos. Nuestro equipo de ingeniería está trabajando activamente para resolver el problema lo antes posible. Vamos a proporcionar más actualizaciones en breve.

2. July 24, 2026 at 9:53 PM UTCmonitoring

   Querido cliente, Nuestro equipo de ingeniería ha identificado e implementado las acciones necesarias para resolver la inestabilidad de Webhook que afecta la latencia de entrega de datos. En este momento, el equipo técnico está realizando un análisis detallado de nuestra capa de datos y sigue vigilando el medio ambiente. Reiteramos que pronto se enviarán nuevas actualizaciones.

3. July 24, 2026 at 10:18 PM UTCresolved

   Resumen e impacto ejecutivo A partir de las 6:05 p.m. (hora Brasilia), se produjo una inestabilidad en el servicio Webhook, lo que dio lugar al fracaso en el procesamiento de eventos y la entrega de notificaciones para operaciones afectadas durante este período. Causa raíz y resolución The incident was caused by an issue with a shared Service Account used across multiple services, resulting in autation failures. Al identificar la causa raíz, el equipo de ingeniería restauró las credenciales y la configuración necesarias. La operación normal se restableció completamente a las 6:29 PM (BRT). Compromiso y próximos pasos Como parte de la mejora continua y la mitigación de los riesgos, el equipo de ingeniería examinará las dependencias de recursos y la gestión del acceso en todos los servicios. Esto evitará problemas de configuración similares en futuros ajustes de infraestructura.

4. August 3, 2026 at 8:00 PM UTCpostmortem

   **Summary** El 24 de julio de 2026, entre las 6:05 PM y las 6:29 PM \(Brasília time\), el servicio de creación y entrega webhook no estuvo disponible durante aproximadamente 24 minutos. The incident was caused by the loss of access to an infrastructure service account during a resource decommissioning process linked to a cluster migration carried out days earlier. La cuenta afectada fue compartida por múltiples servicios sin que se documentara esta dependencia, causando que el servicio webhook pierda su capacidad de autenticación y deje de crear y entregar eventos. # Impact** La creación y entrega de eventos Webhook se interrumpieron durante el período, afectando a 18 usuarios de clientes con más de 1,550 errores registrados. El impacto se encadenó a otros servicios que dependían del mismo flujo de autenticación, causando degradación simultánea en diferentes capacidades de plataforma. *Causa real* La causa raíz se identificó en la configuración de dependencia de servicios. Esta dependencia del servicio no fue documentada ni visible en ningún registro de dependencia. Cuando el proceso de desmantelamiento removió la cuenta como parte de la limpieza de recursos del servicio original, no hubo validación automática para comprobar si la cuenta seguía siendo utilizada por otros servicios activos. La ausencia de esta salvaguardia mantuvo oculta la dependencia hasta que su remoción causó fallas generalizadas de autenticación. **Resolución** El equipo identificó rápidamente la cuenta de servicio inestable como la fuente de las fallas de autenticación. La cuenta fue ajustada manualmente y aplicada al grupo, restaurando el servicio a las 6:29 PM. La duración total del impacto fue de aproximadamente 24 minutos. **Las razones aprendidas** El incidente expuso los riesgos de las configuraciones heredadas que crean dependencias ocultas entre los servicios: un único cambio de recursos durante el mantenimiento planificado fue suficiente para interrumpir múltiples servicios simultáneamente. El proceso de desmantelamiento de los recursos de infraestructura debe incluir la validación automatizada de la dependencia antes de cualquier cambio.

Traducido automáticamente desde la actualización oficial del incidente.

1. July 21, 2026 at 4:39 PM UTCidentified

   Querido cliente, Estamos investigando una inestabilidad en las funcionalidades de IDCloud que afecta a los flujos de autenticación en el viaje de proceso, afectan específicamente el Viaje Web (antes ByUnico). Nuestro equipo de ingeniería se moviliza para resolver el problema lo antes posible. Vamos a proporcionar más actualizaciones en breve.

2. July 21, 2026 at 4:49 PM UTCmonitoring

   Querido cliente, Nuestro equipo de ingeniería ha identificado y aplicado las medidas necesarias para resolver la inestabilidad en las capacidades de flujo de IDCloud afectadas. En este momento, el equipo técnico está realizando un análisis detallado de nuestra capa de datos y sigue vigilando el medio ambiente. Reiteramos que pronto se enviarán nuevas actualizaciones.

3. July 21, 2026 at 6:02 PM UTCresolved

   Resumen e impacto ejecutivo A partir de aproximadamente 12:44 PM (hora de Brasilia) el 21 de julio de 2026, una parte de los usuarios en el viaje reducido a bordo experimentó una carga más lenta de las pantallas iniciales en el flujo. El impacto se observó en todos los entornos donde se utiliza este viaje, afectando la velocidad percibida y, en menor medida, la capacidad de los usuarios para completar el proceso durante este período. Causa raíz y resolución La investigación está en curso para confirmar la causa raíz definitiva del incidente. No hubo impacto en servidores, redes o infraestructuras; se confirmó que el problema estaba aislado a la experiencia en pantalla en el dispositivo del usuario. Como medida de contención, el equipo responsable aplicó un ajuste preventivo a las 1:39 PM (BRT), y los tiempos de carga devueltos a la normalidad en unos minutos. El análisis para validar y confirmar la causa raíz sigue siendo realizado por el equipo técnico. Compromiso y próximos pasos Como parte de la mejora continua de los procesos de respuesta a incidentes, el equipo se compromete a mejorar el flujo de escalada automática de equipos responsables, haciendo que la activación sea aún más directa y efectiva desde el momento en que se abra un incidente. Además, el monitoreo de velocidad de carga se fortalecerá durante la puesta en marcha de nuevos cambios en este viaje, con el objetivo de identificar y corregir posibles regresiones incluso más rápido, minimizando el impacto a los usuarios en situaciones similares que avanzan.

4. August 3, 2026 at 2:01 PM UTCpostmortem

   **Summary** El 21 de julio de 2026, entre las 12:44 PM y 1:43 PM \(Brasília time\), los indicadores de rendimiento de la carga de página para el viaje reducido se degradaron severamente, con el tiempo de carga promedio saltando de ~4.8s a ~8.9s y el p95 alcanzando 31.5 segundos. El incidente fue causado por la limitación de tarifas aplicada por la infraestructura de la nube en las conexiones originadas por el proveedor, lo que impidió que los activos de frontend se cargaran. # Impact** Los usuarios de 32 clientes experimentaron cargas de página extremadamente lentas o fallos de carga completos, con aproximadamente 94 errores de viaje registrados. Los errores de "Tiempo de Initialización" (iniciados cuando la aplicación no se monta en 30 segundos) alcanzaron alrededor de 23 mil ocurrencias durante el período. *Causa real* La causa raíz se identificó en la capa de red de la infraestructura: el proveedor de CDN consolida el tráfico a través de un conjunto limitado de direcciones IP externas. Un pico en nuevas conexiones TCP y apretones de manos TLS originados por estos IPs desencadenaron los mecanismos automáticos de defensa de cadenas de infraestructura de la nube, que comenzaron conexiones delimitación de tarifas incluso antes del procesamiento HTTP. Debido a que estos fallos ocurrieron en la capa de red —antes del procesamiento HTTP— no aparecieron en registros de solicitud estándar, haciendo que el problema sea invisible a la vigilancia convencional y complicando significativamente el diagnóstico. **Resolución** El impacto cesó con la recuperación natural de la tasa límite aplicada por la infraestructura de la nube. La desactivación de un componente, inicialmente señalado como una posible causa, coincidió temporalmente con la recuperación, pero posteriormente se confirmó que no estaba relacionado con el incidente. Los equipos de soporte de los proveedores involucrados identificaron como elementos de seguimiento las correcciones de configuración, que permiten a HTTP Keep-Alive tener un tiempo prolongado y agregar una regla de permiso para los IPs CDN en la capa de protección de bordes. **Las razones aprendidas** El incidente puso de relieve que los fallos en la capa de red entre el CDN y la infraestructura de la nube son invisibles al monitoreo de aplicaciones estándar, creando un punto ciego significativo. Como elementos de seguimiento, el equipo identificó la necesidad de implementar las correcciones de configuración recomendadas por los proveedores y ampliar la observabilidad en la capa de entrega de activos para detectar proactivamente este tipo de degradación.

Traducido automáticamente desde la actualización oficial del incidente.

1. July 21, 2026 at 2:39 PM UTCidentified

   Querido cliente, Estamos investigando una inestabilidad en nuestras capacidades de IDCloud, afectando la creación de procesos y los flujos de detalles del proceso. Nuestro equipo de ingeniería se moviliza para resolver el problema lo antes posible. Presentaremos nuevas actualizaciones en breve.

2. July 21, 2026 at 2:46 PM UTCidentified

   Seguimos trabajando para solucionar este problema.

3. July 21, 2026 at 2:50 PM UTCmonitoring

   Querido cliente, Nuestro equipo de ingeniería ha identificado y aplicado las medidas necesarias para resolver la inestabilidad en las capacidades de flujo de IDCloud afectadas. En este momento, el equipo técnico está realizando un análisis detallado de nuestra capa de datos y sigue vigilando el medio ambiente. Reiteramos que pronto se enviarán nuevas actualizaciones.

4. July 21, 2026 at 4:00 PM UTCresolved

   Resumen e impacto ejecutivo El 21 de julio de 2026, alrededor de las 11:17 AM BRT, se detectó una disminución de la disponibilidad en los flujos de procesamiento y procesamiento de IDCloud. Durante la ventana de impacto, una parte de los clientes experimentó latencia elevada y fallas (tiempos) en estas operaciones, que se propagaron a través de la cadena de servicios dependientes. El impacto efectivo se concentró en una ventana de aproximadamente 23 minutos. En el pico, los indicadores de error y latencia estaban por encima de los niveles operativos normales. Causa raíz y resolución The investigation pointed to the degradation of a read database (replica) supporting these capabilities as the origin. Esta base de datos comenzó a mostrar mayor tiempo de ejecución de cargas y consultas, con la contención interna que frenaba el procesamiento y respaldaba las solicitudes de lectura. Como resultado, los servicios anteriores comenzaron a acumular plazos y desencadenar mecanismos de protección (comparadores de circuito), produciendo el efecto de cascada experimentado por los clientes. Compromiso y próximos pasos Unico está manejando este incidente con un postmortem detallado, que ya está siendo redactado, y celebrará una reunión de revisión post-incidente para consolidar acciones preventivas. Entre los seguimientos ya planteados durante la respuesta se encuentran la preparación de rutinas y consultas diagnósticas para acelerar la identificación de la contención en esta capa de base de datos y mejorar la observabilidad sobre las bases de datos involucradas. Las medidas preventivas detalladas se compartirán en la postmortem. Reafirmamos nuestro compromiso con la estabilidad y fiabilidad de la plataforma y nos disculpamos por las molestias causadas durante el período de inestabilidad. Unico Team.

5. July 28, 2026 at 12:10 PM UTCpostmortem

   **Summary** El 21 de julio de 2026, entre las 11:41 y las 11:43 AM \(Brasília time\), el flujo de creación del proceso se hizo indisponible, con la tasa de error principal de servicio alcanzando 42% y p99 latencia a los 15.75 segundos. El incidente fue causado por la saturación en la base de datos de biometría read replica: el pool de memoria de la base de datos ya no era capaz de servir el conjunto de datos más a menudo accedido, lo que causa que las consultas normalmente rápidas retrocedan a las lecturas del disco, creando una espiral de auto-reforzamiento de las sesiones acumuladas y aumentando latencia. # Impact** Los usuarios de la creación de procesos, autenticación y flujos de pagos a través de múltiples clientes recibieron errores y plazos durante el período. La base de datos primaria se mantuvo intacta durante todo el incidente: el fracaso fue aislado a la réplica de lectura. *Causa real* La causa raíz era saturación: las consultas utilizadas en el flujo de autenticación estaban realizando escaneos extensos en tablas críticas debido a índices perdidos. En condiciones normales, este comportamiento fue tolerado por la infraestructura de la base de datos. Cuando la capacidad de memoria alcanzó su límite y ya no podía mantener los datos más accesibles en caché, cada lectura comenzó a buscar datos del disco, haciendo que el costo de cada consulta sea exponencialmente mayor. Este efecto de colapso abrupto —donde la degradación gradual da lugar a un fracaso generalizado— se hizo auto-reforzamiento a medida que aumentaban las sesiones de espera de respuestas y la contención interna de recursos de base de datos. Además, todo el tráfico de lectura para el flujo crítico se concentró en una sola réplica, sin distribución ni ruta alternativa, eliminando cualquier resiliencia a este tipo de degradación. **Resolución** La base de datos se recuperó naturalmente a medida que se agotaron las sesiones acumuladas, sin necesidad de intervención manual. El equipo se intensificó al equipo de base de datos y supervisó la estabilización de los servicios. El incidente se cerró después de confirmar que se había restaurado la operación normal. **Las razones aprendidas** El incidente reveló deficiencias estructurales en la capa de base de datos: índices perdidos en consultas críticas y concentración de todo el tráfico leído en una sola réplica sin ruta alternativa. Como seguimiento, el equipo priorizó la creación de los índices desaparecidos, la distribución del tráfico de lectura a través de las réplicas y la construcción de corredores de diagnóstico para acelerar la respuesta en futuros incidentes de naturaleza similar.

Traducido automáticamente desde la actualización oficial del incidente.

1. July 20, 2026 at 12:33 PM UTCidentified

   Querido cliente, Hemos identificado una inestabilidad en algunas de nuestras capacidades de IDCloud, afectando a la Get Selfie, creación de procesos y flujos de detalles de procesos para el Viaje Web (antes ByUnico). Los flujos de API Journey (ByClient) no se vieron afectados. Nuestro equipo de ingeniería se moviliza para resolver el problema lo antes posible. Seguiremos en breve con nuevas actualizaciones.

2. July 20, 2026 at 12:35 PM UTCidentified

   Seguimos trabajando para solucionar este problema.

3. July 20, 2026 at 12:39 PM UTCmonitoring

   Querido cliente, Nuestro equipo de ingeniería ha identificado y aplicado las medidas necesarias para resolver la inestabilidad en las capacidades de flujo de IDCloud afectadas. En este momento, el equipo técnico está realizando un análisis detallado de nuestra capa de datos y sigue vigilando el medio ambiente. Reiteramos que pronto se enviarán nuevas actualizaciones.

4. July 20, 2026 at 1:22 PM UTCresolved

   Resumen e impacto ejecutivo Identificamos una inestabilidad que afecta a los flujos de captura y visualización del proceso, así como la autenticación, para el Viaje Web, con impacto entre 09:07 y 09:21 (BRT). El impacto llegó a una parte de los clientes usando este flujo; el Viaje API no fue afectado. Causa raíz y resolución La causa raíz está vinculada a un cambio de configuración aplicado en la producción, que causó una mayor carga en un componente interno de base de datos. Esta carga aumentaba la latencia y los errores en una capa de integración, que a su vez desencadenaba un mecanismo de protección e interrumpió temporalmente los flujos del Viaje Web. El equipo de ingeniería revisó el cambio de configuración para mitigar el problema, y la situación se normalizó poco después. Compromiso y próximos pasos El equipo de ingeniería sigue vigilando el medio ambiente después de la vuelta de los cambios realizados. Un postmortem detallado será compartido por nuestro equipo en los próximos días. Nos disculpamos por la molestia. ¡Unico Team!

5. August 4, 2026 at 2:14 PM 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.

Traducido automáticamente desde la actualización oficial del incidente.

1. July 16, 2026 at 2:02 PM UTCinvestigating

   Querido cliente, Estamos investigando una inestabilidad en nuestro sistema de autenticación para los portales Unico People y también estamos evaluando cuestiones en nuestro servicio de mensajería que afectan a los clientes de IDCloud. Nuestro equipo de ingeniería se moviliza para resolver el problema lo antes posible. Vamos a proporcionar actualizaciones en breve.

2. July 16, 2026 at 2:08 PM UTCmonitoring

   Querido cliente, Nuestro equipo identificó la cuestión y tomó medidas para resolver el incidente. Experimentamos una inestabilidad en nuestro sistema de autenticación para los portales Unico People, así como problemas en nuestro servicio de mensajería que afectan a clientes en el flujo de IDCloud, para SMS y envío de correo electrónico. Nuestro equipo de ingeniería sigue movilizado, supervisando el medio ambiente para asegurar que siga funcionando adecuadamente.

3. July 16, 2026 at 3:28 PM UTCresolved

   Resumen e impacto ejecutivo A las 10:51 AM del 07/16/2026, se identificó un problema en el servicio de autenticación en el portal de admisión Unico People y en mensajería, lo que afectó la entrega de SMS y enlaces de correo electrónico a clientes Unico People y IDCloud, así como la autenticación de clientes B2C en el portal de admisión Unico People. El impacto se limitó a estos dos flujos y no afectó el viaje crítico del producto. El incidente duró aproximadamente 30 minutos hasta la resolución completa. Causa raíz y resolución La causa raíz se identificó como presión de almacenamiento en un nodo del grupo de mensajería, que alcanzó un umbral de disco crítico, degradando el procesamiento de las colas responsables de la entrega de mensajes y la autenticación. El equipo de ingeniería aumentó la capacidad de almacenamiento del clúster aproximadamente a las 10:59 AM, lo que permitió que las colas y los indicadores de monitoreo se normalizaran en cuestión de minutos. El ambiente fue monitoreado hasta que se confirmó la recuperación total, y el incidente fue cerrado a las 11:20 AM. Compromiso y próximos pasos El equipo de ingeniería revisará los criterios de escalada y priorización de alerta para este tipo de degradación, ya que las alertas identificaron correctamente el problema, pero se puede mejorar el flujo de escalada automática al equipo responsable. Se está preparando un postmortem detallado y se compartirá en los próximos días.

4. August 3, 2026 at 12:14 PM UTCpostmortem

   **Summary** El 16 de julio de 2026, entre las 10:12 AM y las 11:10 AM \(Brasília time\), el servicio de mensajería y autenticación fue degradado durante aproximadamente 58 minutos. La causa fue la saturación de disco en uno de los nodos en el grupo de cola de mensajes, que, al llegar al límite configurado, bloqueó automáticamente a todos los editores, causando un atraso de hasta 33 mil mensajes en la cola. El impacto afectó la entrega de enlaces de autenticación vía SMS y correo electrónico, así como el flujo de autenticación de usuario final en el portal de admisión Unico People. # Impact** Los usuarios que esperan enlaces de autenticación a través de SMS o correo electrónico no los recibieron durante el período. Los usuarios finales de un producto de gestión de personas que intentan autenticar en el portal de admisión también no pudieron acceder al servicio. El impacto fue contenido después de la ampliación del disco del cluster. *Causa real* La causa raíz se identificó en el flujo de procesamiento de mensajes: una carga útil excesivamente grande — generada por un componente de auditoría que incluía datos innecesarios— superó el límite de tamaño aceptado por el grupo de cola de mensajes. Dado que fueron rechazados deterministamente en cada intento, estos mensajes fueron enviados a colas de letras muertas después de agotar todas las retries. Estas colas no tenían una política de caducidad o limpieza automática, causando que los mensajes se acumularan indefinida y progresivamente consumieran el espacio de disco del grupo. **Resolución** El disco del cúmulo se amplió a 500 GB por nodo, que normalizó inmediatamente las colas y las métricas del cúmulo. El servicio volvió a la normalidad a las 11:10 AM. La causa de la raíz estructural —la acumulación indefinida en las colas de letras muertas— sigue siendo un elemento de seguimiento que debe abordarse. **Las razones aprendidas** El incidente refuerza que abordar sólo el síntoma \(saturación de disco\) sin investigar la causa raíz de la acumulación garantiza la recurrencia del problema. La ausencia de una política de ciclo de vida \(TTL/expiration\) para las colas de letras muertas y la falta de validación del tamaño de la carga útil antes de la publicación son las dos brechas estructurales centrales a corregir. Además, la alerta de que se señaló la cuestión fue clasificada como baja prioridad, lo que causó un retraso de aproximadamente 38 minutos entre la alerta que se estaba desencadenando y la apertura formal del incidente, un intervalo inaceptable para una degradación crítica de los servicios.

Traducido automáticamente desde la actualización oficial del incidente.

1. July 13, 2026 at 12:51 PM UTCidentified

   Querido cliente, Hemos identificado una inestabilidad en la capacidad de verificación de identidad, generando un error en una pequeña parte de las solicitudes de IDCloud. Nuestro equipo de ingeniería ya está movilizado para el diagnóstico y trabajar para identificar la causa raíz con el fin de normalizar el servicio lo antes posible. En este momento, el equipo técnico está realizando un análisis detallado en nuestra capa de datos para mitigar el impacto. Reforzamos que pronto se enviarán nuevas actualizaciones.

2. July 13, 2026 at 1:06 PM UTCmonitoring

   Querido cliente, Nuestro equipo de ingeniería ha identificado e implementado las acciones para resolver la inestabilidad en la capacidad de verificación de identidad que generaba un error en una pequeña parte de las solicitudes de IDCloud. En este momento, el equipo técnico está realizando un análisis detallado en nuestra capa de datos y sigue vigilando el medio ambiente. Reforzamos que pronto se enviarán nuevas actualizaciones.

3. July 13, 2026 at 1:47 PM UTCresolved

   Resumen e impacto ejecutivo El 13 de julio de 2026, identificamos una inestabilidad en nuestra capacidad de verificación de identidad, generando errores en una parte mínima de las solicitudes de IDCloud, afectando múltiples flujos de autenticación. El problema se detectó a través de alertas automáticas de disponibilidad alrededor de las 9:27 AM BRT, con un ligero aumento de errores ya notificables desde aproximadamente las 8:00 AM BRT y un empeoramiento significativo a partir de las 9:07 AM BRT, alcanzando el impacto máximo alrededor de las 9:49 AM BRT. Causa raíz y resolución The root cause was identified as a gradual change applied to an internal autation component, which caused a failure in session token signature validation. Una vez confirmada la causa raíz, el equipo de ingeniería revertió el cambio y la disponibilidad de servicio volvió a la normalidad. La fase más crítica del impacto duró aproximadamente 44 minutos. Compromiso y próximos pasos La ingeniería está evaluando mejoras en el proceso de validación de cambios para los despliegues graduales que afectan a componentes críticos de autenticación, incluyendo mecanismos de retroceso automático en caso de aumentos de errores durante este tipo de despliegue. Se espera que una posmortem detallada se comparta internamente como un próximo paso.

4. July 20, 2026 at 10:47 PM UTCpostmortem

   # Postmortem: Authentication Flow Instability **Fecha de identificación:** 13 de julio de 2026 **Duración de impacto: **44 minutos ## Summary El 13 de julio de 2026, identificamos una degradación de disponibilidad en los flujos de autenticación de la plataforma. The incident was caused by an incompatibility introduced during a rolling deployment of an internal component responsible for validating security tokens. La causa fue diagnosticada por nuestros equipos de operaciones y revolviendo la estabilidad del sistema restaurada en cuestión de minutos. ## Impacto La degradación duró aproximadamente 44 minutos y afectó simultáneamente múltiples flujos de autenticación en la plataforma, lo que dio lugar a una tasa de error de aproximadamente 0,9% en los servicios orientados al cliente. Durante este período, algunos usuarios finales experimentaron inestabilidad y vieron mensajes genéricos de error \(HTTP 500\) al intentar autenticar. Aunque el evento duró 44 minutos, fluctuó entre el aumento de la latencia y la falta de disponibilidad. ## Root Cause El fracaso fue causado por un defecto de software introducido en una actualización del componente de validación de tokens de seguridad, lo que dio lugar a incompatibilidad entre los casos que ejecutan diferentes versiones. Esta incompatibilidad no se detectó en entornos de prueba, ya que requería la ejecución simultánea y paralela de diferentes versiones. Además, el punto final interno devolvió una respuesta de éxito HTTP incluso cuando la validación falló, lo que impidió que los sistemas automatizados de vigilancia del despliegue detectaran la cuestión y pusieran fin automáticamente al despliegue. Resolución Una vez identificada la causa, el equipo de guardia ejecutó un reverso del componente afectado, restableciendo inmediatamente la disponibilidad de los flujos de autenticación. El incidente fue detectado por alertas automatizadas de SLO en minutos de inicio de la degradación, y la escalada permitió el diagnóstico completo y la mitigación del incidente. ## Lessons Learned Mejoraremos la validación de la versión-compatibilidad en las implementaciones de rodadura, ajustaremos el comportamiento de respuesta HTTP de los puntos finales internos para activar el revolvimiento automático de las implementaciones de fallas, y estandarizaremos el manejo de errores para evitar que los fallos se enmascaran antes de llegar al cliente. ## Compromiso para la mejora continua Los incidentes como éste refuerzan nuestro compromiso de mejorar continuamente la fiabilidad de las plataformas. Tratamos cada incidente como una oportunidad de aprendizaje, revisando nuestros procesos, fortaleciendo los mecanismos de detección y prevención e invirtiendo continuamente en prácticas de ingeniería más robustas. Nuestro objetivo es seguir aumentando la barra en disponibilidad y transparencia para todos nuestros clientes. Unico Team.

Traducido automáticamente desde la actualización oficial del incidente.

1. July 10, 2026 at 4:43 PM UTCinvestigating

   Actualmente estamos experimentando inestabilidad en las capacidades de IDCLOUD. Nuestro equipo técnico ya está investigando la causa raíz. Proporcionaremos actualizaciones tan pronto como se disponga de más información.

2. July 10, 2026 at 5:12 PM UTCidentified

   Hemos identificado una inestabilidad que puede causar tiempo de inactividad temporal o latencia en algunas de nuestras API básicas de verificación y análisis de riesgos. Servicios afectados: - Identidad " Validación: Verificación de Identidad, 1:1 Validación, Retorno de Similitud Serpro - Riesgo & Fraude: Puntaje de Riesgo, Clasificación de Riesgo de Fraude - Documentación " Vida: Reutilización de documentos " Captura, Vida Estado actual > Siguientes pasos: Nuestro equipo de ingeniería ya está totalmente comprometido e investigando la causa raíz. Trabajamos activamente para aislar el comportamiento y restaurar las operaciones normales lo más rápido posible.

3. July 10, 2026 at 5:25 PM UTCmonitoring

   Estado actual > Siguientes pasos Se han aplicado con éxito medidas de mitigación y el sistema está estable. En este momento, nuestro equipo de ingeniería sigue monitoreando activamente el rendimiento de la plataforma para garantizar la estabilidad continua y las operaciones normales. Gracias por su paciencia y comprensión durante este incidente. Sus servicios deberían estar operando normalmente.

4. July 10, 2026 at 5:57 PM UTCresolved

   Resumen e impacto ejecutivo Entre las 1:21 PM y las 2:16 PM (Tiempo Brasilia) el 10 de julio de 2026, identificamos una fluctuación en la disponibilidad del flujo de creación de procesos y viajes relacionados, dando lugar a un aumento temporal en la tasa de error de algunas de nuestras principales API. - Alcance del impacto: El evento afectó exclusivamente la disponibilidad de ciertos viajes durante este intervalo. Los clientes que no experimentaron un aumento de su tasa de error durante este período no fueron afectados. - Integridad de datos: No hubo compromiso con la integridad o seguridad de la información procesada. - Mitigación: Se aplicó una solución de trabajo inicial en unos minutos, deteniendo el volumen de errores. El servicio fue totalmente normalizado a las 2:16 PM, tras la confirmación de estabilidad de nuestros equipos de Ingeniería y Vigilancia. Causa raíz El incidente fue provocado por la inestabilidad en un servicio de infraestructura, seguido de una degradación repentina en la inicialización de componentes internos conexos. Compromiso y próximos pasos Estamos profundamente comprometidos con la resiliencia de nuestra plataforma. Las medidas correctivas y preventivas iniciadas durante el incidente ya se están vigilando para mitigar el riesgo de futuros incidentes de esta naturaleza. - Postmortem: Pronto se compartirá un informe técnico detallado (Postmortem), que contiene el cronograma completo, el análisis arquitectónico y un plan de acción a largo plazo con plazos definidos. Sinceramente nos disculpamos por el impacto y la inestabilidad causados. La confianza de nuestros clientes es nuestra máxima prioridad, y seguimos trabajando continuamente para garantizar la excelencia de nuestros servicios. Sinceramente, Unico Team

5. July 14, 2026 at 2:08 PM UTCpostmortem

   **Summary** El 10 de julio de 2026, entre las 1:21 PM y las 2:09 pm \(Brasília time\), la tasa de error en el flujo de creación de proceso alcanzó aproximadamente el 11% durante unos 9 minutos, con continua degradación de disponibilidad hasta las 2:09 PM. El incidente fue causado por una inestabilidad en el componente de gestión de la configuración de infraestructura, que impidió que las cápsulas de servicio biométrico inicializaran correctamente. El impacto fue amplificado por un comportamiento de consumo de memoria preexistente \(que aumentó la frecuencia de pod restarts\) y por un aumento de tráfico que provocó la creación de nuevas instancias, todas las cuales no pudieron inicializar durante la ventana de inestabilidad del componente de configuración. # Impact** Múltiples flujos se vieron afectados simultáneamente —incluyendo la creación de procesos, autenticación, biometría, pagos y operaciones internas— con errores propagando a través de todos los servicios dependientes del motor biométrico. En su pico, la tasa de error alcanzó el 11%. El número de cápsulas de servicio biométrico disponibles cayó a casi cero en ambos grupos de producción durante la ventana más crítica del incidente. *Causa real* La causa raíz estaba relacionada con una oportunidad de optimización en la lógica de puesta en marcha del servicio biométrico: la aplicación se negó a aparecer si el componente de gestión de la configuración de infraestructura devolvía un fallo durante el arranque, incluso cuando se disponía de datos en caché para su uso como retroceso. Esta lógica trató un desvío de comunicación transitorio de la misma manera que un error de configuración permanente, haciendo que el caché descomposición sea inutilizable exactamente en el momento en que más se necesitaba. Cuando el componente de configuración se hizo inestable, cada cápsula que intenta reiniciar —ya sea debido a la presión de memoria o al autoescalamiento— se atascó en un bucle de falla, incapaz de completar el proceso de inicialización. **Resolución** El equipo tuvo el impacto inicial al aislar el tráfico de uno de los componentes afectados, lo que detuvo el pico de error en aproximadamente 9 minutos. Se siguió la estabilización del componente de gestión de la configuración, permitiendo que las cápsulas vuelvan normalmente. El mismo día se preparó y desplegó una solución de emergencia, eliminando la validación restrictiva que bloqueaba la puesta en marcha, asegurando que el caché descomposición se utilizase de manera transparente en situaciones similares que avanzaban. **Las razones aprendidas** El incidente reveló que el mecanismo de resiliencia del servicio —el caché de retroceso— existía en la arquitectura pero fue neutralizado por la lógica de arranque, que priorizaba la validación estricta de datos sobre la disponibilidad del medio ambiente. Las rutas de inicio para los servicios críticos deben diseñarse para degradar con gracia cuando los componentes de infraestructura son inestables, asegurando la continuidad operacional. **Commitment to Stability and Continuous Improvement** Seguiremos invirtiendo en gran medida en la robustez de nuestra infraestructura para asegurar que nuestros servicios funcionen sistemáticamente a los más altos niveles de eficiencia, seguridad y fiabilidad. Unico Team.

Traducido automáticamente desde la actualización oficial del incidente.

1. July 7, 2026 at 9:22 PM 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. July 7, 2026 at 9:32 PM 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. July 7, 2026 at 10:14 PM 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. July 13, 2026 at 9:18 PM 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. July 6, 2026 at 4:29 PM 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. July 6, 2026 at 4:51 PM 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. July 6, 2026 at 5:25 PM 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. July 13, 2026 at 9:17 PM 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. July 2, 2026 at 10:04 PM 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. July 2, 2026 at 10:05 PM UTCidentified

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

3. July 3, 2026 at 12:04 AM 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. July 3, 2026 at 1:14 AM 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. July 13, 2026 at 8:36 PM 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. June 26, 2026 at 2:10 PM 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. July 3, 2026 at 6:22 PM 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. June 24, 2026 at 6:20 PM 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. June 24, 2026 at 6:31 PM 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. June 24, 2026 at 6:53 PM 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. July 13, 2026 at 7:27 PM 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. June 23, 2026 at 1:24 AM 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 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 como causas. Em breve retornamos com atualizações.

2. June 23, 2026 at 1:39 AM UTCidentified

   Prezado Cliente, Nossa equipe ainda está investigando una causa raiz hacer problema. Em breve traremos mais atualizações. Agradecemos un compreensão.

3. June 23, 2026 at 1:53 AM UTCidentified

   Prezado Cliente, 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. June 23, 2026 at 2:18 AM 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!

5. June 23, 2026 at 2:41 AM 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 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. July 14, 2026 at 1:58 PM UTCpostmortem

   **Summary** El 22 de junio de 2026, a las 9:52 PM \(Brasília time\), el flujo de ahorro de documentos se hizo indisponible debido al agotamiento de un límite de identificación secuencial en la base de datos. Desde ese momento, todas las operaciones de inserción de documentos comenzaron a fracasar, ocultando errores a múltiples servicios dependientes. El incidente duró aproximadamente 86 minutos. # Impact** Varios servicios críticos se vieron afectados simultáneamente, incluyendo flujos a bordo, creación de procesos, autenticación y pagos. En algunos flujos, la disponibilidad disminuyó a menos del 3%. Los clientes habían afectado a los usuarios por fallos o retrasos al intentar operaciones que dependían del ahorro de documentos. *Causa real* La causa raíz estaba relacionada con el tipo de identificador de 32 bits utilizado en la tabla de documentos, que soporta aproximadamente 2,1 mil millones de valores; con el crecimiento natural del volumen récord con el tiempo, se alcanzó este límite, causando que la base de datos ya no pueda generar nuevos identificadores, así que todas las operaciones de inserción comenzaron a fracasar. Dado que no había ningún monitoreo configurado para rastrear la proximidad a este límite, el agotamiento ocurrió abruptamente y sin previo aviso. **Resolución** El equipo identificó la causa raíz en aproximadamente 20 minutos. Como mitigación inmediata, el identificador secuencial fue reconfigurado para utilizar el rango negativo del mismo tipo de datos, liberando aproximadamente otros 2.1 mil millones de valores sin requerir ningún cambio estructural en la base de datos. La solución fue validada en entornos inferiores antes de ser aplicada a la producción. El servicio comenzó a estabilizarse poco después de la aplicación de la solución y fue supervisado hasta que se confirmó la recuperación completa. **Las razones aprendidas** El incidente pone de relieve la importancia de llevar a cabo la vigilancia del uso de identificadores secuenciales en tablas de alto volumen, con alertas tempranas que permiten que el agotamiento se maneje como mantenimiento previsto; adoptando tipos de identificadores de 8 bytes desde el principio para tablas con alto volumen de escritura, incluyendo este cheque en procesos de examen de esquemas; y mapeando y documentando las dependencias críticas de los servicios básicos de persistencia, con el impacto y priorizar la comunicación con los usuarios afectados más rápidamente en el futuro.

Traducido automáticamente desde la actualización oficial del incidente.

1. June 19, 2026 at 1:08 PM 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. June 19, 2026 at 6:34 PM 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. June 19, 2026 at 7:42 PM 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. July 3, 2026 at 8:36 PM 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. June 12, 2026 at 3:29 PM 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. June 12, 2026 at 5:03 PM 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. June 12, 2026 at 6:17 PM 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. June 12, 2026 at 6:31 PM 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. June 12, 2026 at 2:58 PM 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. June 12, 2026 at 5:31 PM 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. June 12, 2026 at 6:00 PM 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