"Sexta 17h, o cadastro parou: o que eu faço nos primeiros 10 minutos"

"Sistema caindo."

É o resumo que um programador brasileiro deu, num fórum, do sistema feito com IA que ele tinha sido chamado pra arrumar. Duas palavras. Quem tem app no ar sabe que elas chegam sempre na pior hora.

Então vou contar uma sexta. Não é um caso específico: é a soma de várias, e é o roteiro que eu sigo de verdade, contado minuto a minuto.

17h02

Chega no WhatsApp: "tentei me cadastrar e não foi". Print de uma tela com erro.

O instinto é abrir o chat da IA e digitar "o cadastro parou, conserta". Eu já fiz isso. Qualquer um que tem app já fez. E quase sempre piora, por um motivo simples: consertar por cima de uma coisa quebrada é somar uma mudança nova a um estado que você não entende. Em meia hora você tem dois problemas e não sabe qual é qual.

Não é falta de disciplina de quem faz isso. É que ninguém te mostrou a ordem. O livro de confiabilidade do Google, escrito pra quem cuida de sistema grande, diz com todas as letras: na primeira resposta a uma queda, o instinto de sair procurando a causa deve ser ignorado. A prioridade é "fazer o sistema funcionar o melhor possível nas circunstâncias". Eles chamam isso de estancar o sangramento.

Vale pra app de cinco usuários também.

17h03: confirmo que é real

Janela anônima, rede do celular, uma conta nova. O cadastro falha pra mim também. Não é o celular da pessoa. Esse teste eu já detalhei, leva três minutos.

17h05: guardo a prova antes de mexer

Print da tela de erro, com a hora. Abro o log (o registro do que o servidor fez, linha por linha) e copio a linha vermelha pra um bloco de notas. O mesmo livro do Google lembra que estancar rápido não impede de preservar a evidência. E no plano gratuito de alguns bancos, o log de hoje some amanhã.

Isso leva um minuto. Sem ele, na segunda-feira eu vou investigar de memória.

17h06: volto pro último ponto que funcionava

Não peço conserto. Abro o histórico de versões e volto pra versão de antes da última mudança. No Lovable, a própria documentação diz que dá pra ver uma versão antiga, voltar pra ela, e que nada se perde: as mudanças depois daquele ponto continuam no chat e podem ser reaplicadas. No git, é voltar pro ponto marcado.

Um aviso que eu nunca esqueço: voltar o código não volta o banco. Se a última mudança mexeu numa tabela, o código de ontem pode encontrar o banco de hoje e reclamar.

17h08: confiro

Conta nova, cadastro, entrou. Estabilizou. Não sei a causa ainda, e está tudo bem. O app está de pé.

17h09: aviso quem usa

Pra quem reclamou, e pra onde o link foi divulgado:

"O cadastro ficou fora do ar entre umas 15h e 17h de hoje. Já voltou. Se você tentou nesse horário e não conseguiu, tenta de novo, por favor. Desculpa o transtorno."

Sem "foi a IA", sem explicação técnica. Pro cliente, o app é seu. E repara num detalhe que dói: quem falhou no cadastro não deixou contato. Essa gente só volta se vir o aviso onde encontrou o link.

17h10: anoto, e só então investigo

Três linhas no bloco de notas: a hora que chegou a reclamação, a última mudança antes dela, o que eu fiz. Pronto. A investigação fica pra depois do jantar ou pra segunda, com calma, com o log guardado e com o pedido pra IA diagnosticar antes de mexer.

Dez minutos. Nenhum código escrito. O cliente de volta.

O que fazer hoje, com o app funcionando

A ordem acima só funciona se você souber onde clicar antes de precisar. Na hora do susto, ninguém lê documentação. Então hoje, com calma, faça duas coisas.

1. O cartão dos 10 minutos. Um papel, colado na borda do notebook ou salvo como "quando quebrar":

QUANDO QUEBRAR
1. Não peço conserto pra IA.
2. Confirmo: janela anônima + rede do celular + conta nova.
3. Guardo: print com hora + linha do log.
   O log fica em: ______________________
4. Volto: o botão de voltar versão fica em: ______________
   A última mudança mexeu no banco? Pergunto antes.
5. Confiro: faço o fluxo que quebrou de novo.
6. Aviso: mensagem pronta abaixo. Mando em: _____________
7. Anoto 3 linhas. Investigo depois.

Preencha os espaços em branco com o que vale no seu app. Se algum você não sabe preencher, achou a sua primeira parede.

2. O ensaio. Com o app de pé, cronometre: volte pra versão anterior, confira que o app abre, e restaure de novo a atual. É o simulado de incêndio. Se levou mais de cinco minutos ou você travou em algum clique, melhor descobrir numa quarta calma do que numa sexta às 17h.

Era uma parede de várias

Voltar rápido é só a primeira. Ela depende de ter um ponto de retorno marcado, que depende de mudar uma coisa por vez. E ela não resolve por que quebrou, nem impede a próxima, nem garante que o banco volta junto.

Numa ordem que eu uso, isso fica na fase de operar, e ela vem depois de construir e estruturar: Construa, Estruture, Opere. Quem chega na sexta com o código no seu nome, os testes que rodam e o botão de voltar ensaiado tem uma sexta chata. Quem chega sem, tem uma noite longa.

Comece pelo cartão. É um papel.

Fontes

• Google, Site Reliability Engineering, capítulo 12, "Effective Troubleshooting", seção Triage ("Ignore that instinct!", "make the system work as well as it can under the circumstances", "preserve evidence"): https://sre.google/sre-book/effective-troubleshooting/
• Lovable, FAQ (ver e voltar pra uma versão anterior; mudanças posteriores continuam no chat e podem ser reaplicadas): https://docs.lovable.dev/introduction/faq
• A fala do início é de um programador num fórum brasileiro, 2026, e está no swipe file da pesquisa deste blog (relato, não estatística).