# Como ler o post-mortem Abacate Pay

> Published 2026-09-26T19:50:08.852Z on https://www.crazystack.com.br/pt/p/como-ler-o-post-mortem-abacate-pay/
> Source video: https://www.youtube.com/watch?v=NYHd95PKvXg

A Abacate Pay não caiu por falta de teste: caiu porque não conseguia recriar sua infraestrutura crítica em outro provedor. O post-mortem Abacate Pay de janeiro de 2026 é um estudo raro de transparência em fintechs brasileiras, e o maior erro não foi técnico, foi de comunicação com o cliente.

## O que aconteceu no post-mortem Abacate Pay

O post-mortem Abacate Pay documenta uma indisponibilidade de mais de 36 horas, entre 16 e 17 de janeiro de 2026, durante a migração da versão V1 para a V2 da plataforma. O relatório público foi assinado por Christopher Ribeiro, CTO da [Abacate Pay](https://www.abacatepay.com), fintech brasileira de recebimentos. O plano previa minutos de downtime; o resultado foi impacto intermitente em logins, painel e operações financeiras.

A empresa [anunciou publicamente o incidente](https://www.abacatepay.com) afirmando que a plataforma voltou ao ar e estável, sem perda de dados financeiros ou inconsistência de saldos confirmadas. O ponto crítico do relatório é honesto: embora a empresa use estratégia multi-cloud, nem todos os componentes críticos estavam replicados entre provedores. Isso limitou severamente rollback e failover quando a infraestrutura principal falhou.

Lucas Montano, no vídeo de janeiro de 2026, declarou ser amigo pessoal do CEO Daniel e analisou o relatório sem tom de ataque. Ele destaca que erros em migração são inerentes ao software: até o [Stripe](https://stripe.com), com mais de uma década de experiência em pagamentos, já passou por quedas longas. Software quebra; a diferença está em quão rápido você recupera e como comunica.

## Linha do tempo do incidente: onde tudo começou a desandar

A migração começou às 00h20 de 16 de janeiro de 2026, com acesso da API de produção ao banco de dados interrompido. Até a 1h35, o plano seguiu como esperado: jobs assíncronos concluídos, dump completo do banco, script de migração executado e banco principal restaurado. A nova infra de aplicação passou por testes automatizados e de carga sem falhas aparentes.

O primeiro sinal real veio às 3h, quando o dashboard apresentou bugs funcionais. Às 3h45, o disco da nova infraestrutura cresceu até o limite e a aplicação perdeu resposta. Montano comenta que disco estourado em produção, na maioria das vezes, tem log como suspeito principal. A partir daí, a linha do tempo vira uma sequência de falhas intermitentes, o pior tipo de falha segundo ele: problema que vai e volta desgasta mais que uma queda consistente.

Dois pontos do relatório merecem sublinhado:

## Rollback x failover: por que a volta atrás falhou

Rollback é reinstalar uma versão anterior que se sabe funcional, como fazer checkout na tag V1 e reiniciar o serviço. Failover é trocar automaticamente para um sistema reserva, em outro servidor ou outra cloud, quando o principal falha. São mecanismos diferentes, e a Abacate Pay não conseguiu executar nenhum dos dois com rapidez.

O problema central do rollback foi a mudança de estrutura de dados. A V2 operava sobre uma organização de dados completamente nova, com filas, tabelas e fluxos redesenhados. Reverter para a V1 exigia reconciliar informações geradas na V2 com uma estrutura incompatível. Montano resume: rollback só funciona bem quando você conhece todos os gargalos de sincronização de dados, e isso precisa ser previsto antes da migração.

Já o failover esbarrou na ausência de replicação ativa entre provedores. A infra principal não podia ser recriada automaticamente em outro ambiente, no mesmo provedor ou em outro cloud, sem construção manual do zero. Tentativas de recuperação da VM principal falharam com perda de acesso administrativo, e o provedor não ofereceu SLA e gerenciamento adequados das instâncias.

## Infraestrutura como código: a lição mais cara

Infrastructure as Code (IaC) descreve VPCs, sub-redes, servidores, bancos de dados, balanceadores e firewall em arquivos versionados, geralmente YAML ou JSON. Com IaC, recriar o ambiente completo em outro provedor é questão de executar o código. Sem IaC, como o incidente mostrou, é questão de horas ou dias de trabalho manual sob pressão.

O relatório lista como ação corretiva tornar a infraestrutura totalmente reprodutível e versionada como código. O [Terraform](https://www.terraform.io) é a ferramenta mais citada para cenários multi-cloud, porque funciona de forma independente de provedor. Quem opera só na AWS pode usar o [AWS CloudFormation](https://aws.amazon.com/cloudformation/), que é especializado nesse provedor.

Para Montano, essa foi a falha mais crítica do caso: se o ambiente da Abacate Pay fosse descrito em código, a reconstrução em outro provedor teria levado minutos em vez de várias horas. Colocar uma fintech no ar manualmente do zero, em meio a um incidente, é algo que ele classifica como tarefa para poucos.

## Proxy de DNS desligado: o detalhe que derrubou a recuperação

À 1h20 de 17 de janeiro, a equipe descobriu que o proxy no DNS não havia sido habilitado. Sem o proxy, o tráfego malicioso chegava direto aos servidores, junto com clientes legítimos retornando à plataforma. A performance ficou comprometida justamente no momento da recuperação.

Serviços como o [Cloudflare](https://www.cloudflare.com) funcionam como camada de proteção na frente da aplicação, filtrando DDoS, bots e acessos suspeitos. Sem essa camada, a aplicação fica exposta a qualquer pico de tráfego.

Montano traz um alerta que vale para qualquer SaaS: nem todo tráfego que parece ataque é ataque. Um cliente seu pode criar, sem querer, um loop de retentativa agressivo num integration bug e derrubar sua aplicação. O dev do cliente escreve um retry mal feito e transforma o próprio cliente em vetor de queda. Por isso o relatório lista checklists obrigatórios para operação de alto risco envolvendo DNS e proxy DNS.

## Comunicação em incidente: corrigir primeiro ou avisar primeiro?

A Abacate Pay optou por comunicar diretamente os clientes transacionando durante o incidente, sem atualizações constantes no X. Um comentário de um CTO experiente no thread virou o ponto mais citado do caso: a escolha de corrigir primeiro é a mais racional, mas a clientela prefere o oposto. Sua orientação é atender o cliente primeiro e resolver o problema depois.

A frase que resume a lição: transparência compra um tempo de paciência que a rapidez de um bug fix nunca alcançará. Em pagamentos, a incógnita do que está acontecendo drena mais energia do cliente do que a própria queda. Downtime é tolerado; desconfiança de que algo errado está sendo escondido, não.

Montano acrescenta um ponto de processo: até uma migração de minutos na madrugada precisa de e-mail prévio aos clientes, com horário da janela e canal de comunicação para imprevistos. Bancos fazem downtime anunciado em manutenção, e uma plataforma de pagamentos não é diferente. O relatório incorpora a lição com janelas de manutenção comunicadas previamente e processo consistente de comunicação externa.

## Go/no-go e as ações corretivas listadas no relatório

O relatório fecha com uma lista de ações para evitar repetição do incidente. Montano defende que o critério mais importante é o go/no-go rigoroso: no caso, por volta das 3h40 do primeiro dia, com bugs funcionais e disco no limite, a decisão racional seria cancelar a migração e reverter tudo. A V2 poderia esperar outra madrugada.

As ações anunciadas cobrem os três eixos do incidente:

## FAQ

- **Quanto tempo a Abacate Pay ficou fora do ar?**

Mais de 36 horas de impacto intermitente e contínuo, entre 16 e 17 de janeiro de 2026. O impacto afetou login, painel, envio e recebimento de pagamentos. Não houve perda de dados financeiros ou inconsistência de saldos confirmadas, segundo o post-mortem.

- **Por que o rollback da Abacate Pay falhou?**

A V2 operava sobre uma estrutura de dados completamente nova, então reverter para a V1 exigiria reconciliar dados gerados na V2 com um formato incompatível. Além disso, a infraestrutura principal não podia ser recriada automaticamente em outro ambiente, o que inviabilizou failover rápido.

- **O que é infraestrutura como código e por que importa nesse caso?**

IaC descreve servidores, redes, bancos e balanceadores em arquivos versionados, usando ferramentas como Terraform. Com IaC, recriar o ambiente em outro provedor leva minutos. Sem IaC, a Abacate Pay precisou reconstruir a plataforma manualmente do zero, o que consumiu várias horas do incidente.

- **Houve perda de dinheiro dos clientes?**

O post-mortem afirma que não houve perda de dados financeiros ou inconsistência de saldos confirmadas. O impacto foi de indisponibilidade: falha no envio e recebimento de pagamentos e degradação severa de performance em momentos de recuperação parcial.

- **O que a V2 da Abacate Pay trouxe de novo?**

A V2 foi reconstruída do zero e inclui uma camada de IA que permite operar a plataforma por comandos, como listar cobranças não pagas ou gerar cupons para clientes em churn. O CEO Daniel demonstrou a funcionalidade em vídeo após a estabilização da plataforma.

[Source video](https://www.youtube.com/watch?v=NYHd95PKvXg)