Quando uma dependência derrete: nosso post-mortem do incidente de 22–23 de junho
Em 22 de junho de 2026, nosso principal parceiro de tarefas assíncronas e gerenciamento de filas, Trigger.dev, sofreu uma falha catastrófica e em cascata em múltiplas regiões. Como a infraestrutura central da nossa plataforma depende fortemente do motor deles para processar jobs em segundo plano, webhooks e workflows críticos, essa falha a montante criou imediatamente um incidente de alta severidade para a nossa própria aplicação. A Trigger.dev publicou aqui o próprio detalhamento transparente de engenharia: [Relatório de incidente da Trigger.dev (22 de junho de 2026)](https://trigger.dev/blog/incident-report-jun-22-2026). Abaixo está o detalhamento alinhado de como a falha da infraestrutura deles se mapeou diretamente à nossa linha do tempo de engenharia interna e de como saímos de um apagão total.
A linha do tempo alinhada
| Hora (UTC) | O que aconteceu a montante (Relatório completo) | O que aconteceu internamente / nossa experiência |
|---|---|---|
| 22 de junho, 19:00 | O gatilho: falta de capacidade na AWS em us-east-1 faz cerca de 10.000 execuções se acumularem nas filas a montante. | Nossas tarefas em segundo plano começam a travar discretamente. As filas começam a crescer por baixo dos panos. |
| 22 de junho, 20:09 | O colapso: o plano de controle do Kubernetes a montante chega a 100% de CPU, perde o quorum do banco de dados e **us-east-1** fica totalmente fora do ar. | Nosso ambiente de produção para de processar execuções. Milhares de tarefas em toda a plataforma ficam presas no backlog. |
| 22 de junho, 21:58 | A equipe de engenharia a montante está ativamente lutando contra um loop de "tempestade de reconexão". | Incidente reportado: taxas elevadas de falha são notadas, e uma sala interna de incidente é criada. |
| 23 de junho, 00:59 | O provedor a montante recomenda que os usuários mudem manualmente as cargas de trabalho para a região eu-central-1. | Líder do incidente designado: a sala de resposta ao incidente é totalmente ativada com um líder designado para lidar com a avaliação entre regiões. |
| 23 de junho, 01:01 - 02:10 | O provedor a montante implanta uma atualização emergencial no painel para permitir mover execuções em massa entre regiões. | Mitigação ativa: às 01:10, a equipe cancela manualmente nossas execuções nos EUA que estavam na fila para liberar a capacidade bloqueada de execução da nossa conta e direciona todo o novo tráfego para a região europeia. Às 02:10, as mensagens voltam a ser processadas. |
| 23 de junho, 02:02 - 02:33 | O provedor a montante está escalando manualmente o armazenamento de apoio do banco de dados. | Severidade elevada para crítica: mais de 30.000 de nossas próprias tarefas agora estão na fila esperando. A equipe publica uma atualização de status crítica na nossa página pública de status. |
| 23 de junho, 04:35 - 05:05 | As atualizações da infraestrutura a montante reduzem a velocidade de execução de volta ao passo de tartaruga. | O gargalo de webhook: as taxas de processamento caem. Às 05:05, identificamos que nossa fila de entrega de webhooks é o principal gargalo que se recusa a esvaziar. |
| 23 de junho, 08:38 | A segunda cascata: o redirecionamento do tráfego global sobrecarrega a região europeia do provedor, derrubando-a completamente. | Paralisação total: agora as duas regiões a montante estão, na prática, mortas. Temos mais de 13.000 tarefas congeladas em andamento, totalmente à mercê da recuperação a montante. |
| 23 de junho, 10:34 | A engenharia a montante está com dificuldade para trazer de volta a região europeia. | Implantação do disjuntor: percebendo que a camada principal de processamento em segundo plano está completamente travada, nossa equipe muda da mitigação de infraestrutura para uma solução arquitetural de desvio. Implantamos um hotfix emergencial em todos os ambientes principais da aplicação e da API para desativar temporariamente o gerenciamento de tarefas assíncronas. |
| 23 de junho, 10:41 | O provedor a montante ainda está trabalhando para redimensionar os nós do plano de controle. | Alívio imediato: o desvio arquitetural funciona perfeitamente. Ao contornar as filas congeladas em segundo plano, processos críticos do app passam a usar caminhos de execução direta. A engenharia confirma: "Os e-mails estão fluindo de novo." |
| 23 de junho, 17:06 | O provedor a montante finalmente estabiliza as duas regiões e restaura as velocidades de processamento. | Fila limpa: a engenharia confirma que nossas filas nas duas regiões foram totalmente esvaziadas. O desempenho do sistema volta ao normal. |
| 23 de junho, 19:31 | A estabilidade pós-recuperação se mantém. | Incidente resolvido: os sistemas estão totalmente normais; a equipe entra no fluxo de revisão pós-incidente. |
Principais aprendizados e nossa avaliação da experiência
Embora o post-mortem a montante tenha se concentrado em ajuste de banco de dados e infraestrutura de cluster, nossa avaliação interna foca em degradação graciosa e resiliência arquitetural.
1. O poder do "botão de desligar"
O momento decisivo da nossa recuperação aconteceu às 10:34 UTC. Quando a região secundária do nosso provedor caiu, deixamos de tentar gerenciar filas em segundo plano e passamos a implementar um desvio estrutural.
-
O desvio: ao implantar uma mudança global de configuração para desativar as tarefas em segundo plano, basicamente cortamos o cabo da nossa dependência quebrada. Isso forçou transações críticas do usuário, como e-mails de confirmação de reserva, a contornar temporariamente o motor quebrado em segundo plano e processar diretamente.
-
Em 7 minutos, as funções essenciais do negócio foram totalmente restauradas para nossos usuários, provando que ter caminhos de fallback integrados e ativáveis para grandes dependências de terceiros é um requisito inegociável para alta disponibilidade.
2. Gerenciando armadilhas de concorrência entre múltiplas regiões
Durante a fase de mitigação, navegar por uma configuração multirregião trouxe limitações inesperadas da plataforma. Tarefas presas em uma fase intermediária na região dos EUA continuaram consumindo a capacidade global de execução da nossa conta mesmo depois que apontamos nossa aplicação para a Europa.
- Identificar e executar um cancelamento em massa direcionado do pool travado dos EUA às 01:10 foi fundamental para liberar capacidade de execução na nossa recém-direcionada região europeia.
3. Fortalecimento do raio de impacto a montante
Embora nosso fallback emergencial tenha salvado os fluxos de missão crítica, como e-mail, ainda tínhamos mais de 13.000 tarefas mortas em filas congeladas a montante até o provedor se recuperar totalmente.
- O caminho futuro: daqui para frente, estamos avaliando o design de um buffer mais localizado. Para jobs em segundo plano ou webhooks de saída, estamos avaliando implementar uma fila interna leve de staging que possa armazenar tarefas localmente durante um apagão a montante, garantindo a ordem correta durante o replay.
Resumo
No fim, nossa equipe de engenharia diagnosticou com sucesso uma armadilha complexa de concorrência entre múltiplas regiões, redirecionou o tráfego e implantou um desvio arquitetural criativo que resgatou a experiência dos nossos usuários horas antes de o provedor conseguir estabilizar a infraestrutura.
Sabemos que este foi um momento muito difícil para a equipe da Trigger.dev. Temos respeito por eles e seguimos com uma parceria ótima. Este post serve apenas para compartilhar o nosso lado do incidente e como nossa equipe reagiu.