Instabilidade no Serviço de Integração By Unico

Update timeline

1. investigating May 05, 2026, 04:08 PM UTC

   Prezado Cliente, Nossa monitoração proativa detectou um comportamento irregular nas capacidades de retorno do ByUnico. Embora a causa exata ainda esteja sob investigação, isso pode se manifestar como lentidão ou intermitência no serviço gerando erro 415 em determinados fluxos. A equipe de tecnologia está executando todos os procedimentos de diagnóstico no ambiente para identificar as causas. Em breve retornamos com atualizações.

2. identified May 05, 2026, 04:14 PM UTC

   Prezado Cliente, Detectamos o motivo do impacto nos retornos do ByUnico, causando instabilidade aos clientes em determinados fluxos. A 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

3. monitoring May 05, 2026, 04:45 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!

4. resolved May 05, 2026, 04:58 PM UTC

   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!

5. postmortem Jul 14, 2026, 01:40 PM UTC

   **Summary** On May 5, 2026, between 11:20 AM and 1:00 PM \(Brasília time\), the process creation flow experienced failures with HTTP 415 errors for approximately 4% of requests, totaling 8,453 unsuccessful attempts over roughly 100 minutes. The incident was caused by an incompatible change introduced to the platform's protocol descriptor set, which was loaded by pods undergoing an update during a canary rollout, causing all requests routed to those pods to be rejected. ‌ **Impact** Users from multiple clients using the process creation flow received errors during the period. The failure specifically affected the pods undergoing update, while stable pods continued operating normally — which limited the impact but created inconsistent behavior for a portion of users. ‌ **Root Cause** The incident was caused by an incompatible change introduced to the protocol descriptor set shared across all platform environments, which propagated immediately to any pod that was restarted or created, without going through progressive validation. The pods in the canary rollout, being the first to load the new descriptor, began rejecting all incoming requests; since there were no alerts configured for this error class nor evaluation of this failure pattern in the canary analysis process, the rollout proceeded undetected internally, and the incident was only identified through customer reports. ‌ **Resolution** The team identified the canary pods as the source of the errors and halted the ongoing rollout, which immediately stopped request routing to the affected pods. In parallel, the incompatible protocol descriptor change was reverted. With these two actions, the service stabilized. ‌ **Lessons Learned** The incident reinforces the need to isolate or version protocol descriptors by environment, to prevent incompatible changes from automatically propagating to production; to expand monitoring coverage and service quality indicators to include anomalies in critical error classes, since detection relied on customer reports rather than internal alerts; and to implement mechanisms that prevent merging changes with unresolved critical alerts identified during code review.