← todos os posts
Manutenção 9 min de leitura

"O app quebrou e você não sabe programar. E agora?"

São 23h, o cliente mandou print e você não lê código. Seis passos numerados, na ordem que funciona: primeiro estabilizar, depois descobrir a causa.

"Sistema caindo."

"Sistema que só funcionava usando uma conta específica. Qualquer outra conta retornava erro."

As duas frases são de um programador brasileiro, num fórum, descrevendo o sistema feito com IA que ele foi contratado pra arrumar. E tem a versão de quem estava do outro lado, em outro fórum: "Agora estamos correndo de lá para cá procurando um programador."

Se você chegou aqui às onze da noite, com um print do cliente na tela, este post é pra ler agora. É numerado, cada passo diz quanto tempo leva, e a lição de moral fica pra amanhã. Uma regra só, que é o post inteiro:

Primeiro estabilizar. Depois descobrir a causa.

O instinto é o contrário: abrir o chat e digitar "conserta". É por isso que quase todo mundo piora. Consertar sem saber a causa é mandar a IA chutar em cima de um estado que você não entende; cada chute é uma mudança nova somada à que já quebrou, e em uma hora são três problemas. Quem lida com incidente há anos devolve o serviço primeiro e investiga depois. Não é técnica. É ordem.

Passo 1: é só comigo? (3 minutos)

Descubra se o app quebrou ou se a sua tela quebrou. Três testes:

  1. Janela anônima (Ctrl+Shift+N no Chrome; Cmd+Shift+N no Mac). O navegador guarda cópia das páginas que já visitou, o cache, e mostra a cópia velha com cara de nova. A anônima não tem cópia.
  2. Outro aparelho.
  3. Rede do celular. Desligue o Wi-Fi. Problema de rede aparece numa e some na outra.

Na minha experiência, metade dos "caiu" morre aqui; não é medição, é o que eu vejo. Se funcionou em janela anônima pela rede do celular, o app está de pé e o problema está entre o cliente e ele. Manda pro cliente: "abre em janela anônima e me diz".

Se continuou quebrado, um quarto teste: a página de status da plataforma. Toda plataforma séria tem uma, sem login: status.lovable.dev, status.supabase.com (o Supabase é o banco atrás do Lovable e de muita outra). Na semana em que escrevo, a do Lovable lista "builds falhando para alguns usuários" em 16 de setembro, e a do Supabase, uma falha no serviço de login (Auth) no mesmo dia. Se o seu login parou nessa noite, não era o seu app. Clique em Subscribe to updates: aviso por e-mail antes do cliente.

Incidente aberto? Espere e avise o cliente. Nada? Passo 2.

Passo 2: o que mudou nas últimas 24 horas? (2 minutos)

Quase todo defeito novo tem uma mudança recente atrás. O trabalho aqui é listar suspeitos, num papel:

  • Você mudou algo? Pediu algo pra IA hoje? Publicou? Cadastrou uma chave? O histórico de versões da plataforma lista cada edição com hora; anote: "18h10: pedi filtro por data. 18h40: publiquei".
  • A plataforma mudou algo? Um usuário do Lovable escreveu, em 2025: "my webApp completely broke twice just because Lovable changed something", meu app quebrou duas vezes só porque o Lovable mudou algo. Acontece, e não se conserta no seu código.
  • Um serviço de fora mudou? Pagamento, e-mail, login pelo Google, WhatsApp. Cada um tem calendário próprio, e ele não é seu.

Mudança sua hoje? Passo 3. Nenhuma? Pule pro 4.

Passo 3: volte pro último ponto que funcionava (5 minutos)

Achou a mudança de hoje? Não peça pra consertar. Volte. Já expliquei como restaurar uma versão no Lovable e no Replit. Hoje acrescento a Vercel, e dois avisos.

Na Vercel, o botão se chama Instant Rollback, no bloco da publicação em produção. A documentação (julho de 2026) diz que o plano gratuito volta só pra publicação anterior; os pagos, pra qualquer uma que já esteve no ar. E o diálogo de confirmação lembra o que vale pra qualquer plataforma: as variáveis de ambiente (as chaves guardadas fora do código) ficam como estão, e o banco pode ter mudado desde aquela versão.

Esse é o primeiro aviso: em várias plataformas, voltar o código não volta o banco. Bolt, Lovable e Replit escrevem isso, já mostrei onde. Se a mudança de hoje criou uma coluna ou uma tabela, o código de ontem encontra o banco de hoje e pode quebrar de um jeito novo. Antes de restaurar, pergunte pra IA, sem autorizar nada:

"Não mude nada. A última mudança alterou alguma tabela ou coluna do banco? Responda só sim ou não, e qual."

Não? Restaure. Sim? Restaure mesmo assim, sabendo que o erro seguinte pode ser esse desencontro.

O segundo aviso: depois de voltar, confira. Rode a foto do antes, os cinco fluxos que não podem quebrar. Verde? Estabilizou. O cliente tem o app de volta, você perdeu uma tarde, e a investigação fica pra amanhã. Uma tarde é o preço de um app inteiro de pé.

Continuou quebrado? Passo 4.

Passo 4: leia o recado que o app deixou (10 minutos)

Quando um app quebra, ele deixa o motivo escrito. Chama log: o registro, linha por linha, do que o servidor fez e do que deu errado, com hora. Ninguém mostra isso pra quem não é dev, porque dev acha óbvio onde fica. Documentação oficial, conferida nesta semana:

Onde o seu app roda Onde está o log O detalhe que importa
Lovable More → Cloud → Logs Não atualiza sozinho: clique em Refresh. Filtro de status pra mostrar só erro. Volta até 5 dias.
Replit Tools → Replit Cloud → Monitoring Filtro Errors only. Guarda 30 dias.
Supabase Logs, no menu do projeto Filtro Level = error. Guarda 1 dia no plano gratuito, 7 no Pro.
Vercel Aba Logs Já mostrei.

Leia de novo a linha do Supabase: um dia. No plano gratuito, o recado de hoje à noite some amanhã à tarde. Copie hoje.

O que fazer com o log não é entender. É achar a linha vermelha da hora em que o cliente reclamou, copiar inteira e colar num bloco de notas, com a hora. Depois, cole no chat com o pedido de sempre: "não conserte ainda; me explique em português o que esta linha diz e o que eu confiro antes de você mudar qualquer código". Tradução primeiro; conserto só no passo 5.

Passo 5: como pedir socorro direito (5 minutos)

Quem manda "não funciona" recebe de volta "o que você verificou?". Vale pra IA, pro fórum e pro programador, e a pergunta é justa. Você acabou de conferir quatro coisas. Escreva assim:

SOCORRO — 20/09, 23h10

O que o cliente vê: "erro ao salvar pedido" (print, 22h48)
É só comigo?  janela anônima: igual · rede do celular: igual
              status da plataforma: sem incidente
O que mudou nas 24h: 18h10 pedi filtro por data · 18h40 publiquei
O que eu já fiz: voltei pra versão das 17h → continuou quebrado
O log diz: [linha colada, com a hora]

O que eu pedi pra IA:    "adicionar filtro por data"
O que ela respondeu:     "pronto, adicionei e ajustei a consulta"
O que eu verifiquei:     filtro aparece; salvar dá erro desde então

As três últimas linhas são as que ninguém escreve e as que mais valem. O que eu pedi, o que a IA respondeu, o que eu verifiquei. Separadas, porque o que a IA disse que fez não é o que ela fez, e você já sabe disso. Quem lê o socorro precisa distinguir fato de relato.

Com esse bloco colado numa sessão nova do chat, a IA para de chutar e passa a diagnosticar. Peça diagnóstico e uma correção só, pequena, com a frase verificável combinada antes. Se falhar duas vezes, não mande a terceira.

Passo 6: quando chamar alguém, e o que ter na mão

Quatro sinais, e um basta:

  1. O dado está errado ou sumiu. Tela se refaz; dado de cliente, não.
  2. Voltar não estabilizou, e o log aponta pra algo que você não deveria tocar sozinho: banco, chaves, login.
  3. Duas rodadas de IA e nada, com cliente esperando.
  4. Passou de uma hora, e tem gente pagante do outro lado.

O que ter na mão, porque é o que separa uma hora cobrada de uma noite cobrada: o bloco de socorro do passo 5; o inventário de onde cada coisa mora e em nome de quem, porque "não sei a senha do banco" é onde a primeira hora vai embora; o ponto de retorno marcado; o log copiado.

E o que pedir: horas, no ponto exato, com três entregas: o que causou, o que foi feito, e como eu confiro que está resolvido. Se vier "é só reescrever isso", devolva as cinco palavras: me mostra onde eu clico.

O programador da frase lá do começo terminou o relato assim: "agora estou refatorando tudo". Talvez o seu app precise disso um dia. Não é a conversa das 23h. Quem te vende a reforma da casa com a cozinha pegando fogo não está te ajudando.

Enquanto isso, o cliente

Uma mensagem, no primeiro minuto: "Vi. Estou olhando. Te aviso em 30 minutos." E avise, mesmo que seja "ainda não". O que destrói confiança não é o app cair; é o silêncio. E nunca "foi a IA": pro cliente, o app é seu. Ser dono é isso, na noite ruim também.

Salve com o nome "quando quebrar"

Seis passos, uns 25 minutos até estabilizar ou saber que precisa de alguém. Na hora você não vai lembrar da ordem, e a ordem é tudo.

Há um checklist que eu uso pra separar protótipo de produto, e a pergunta 10 dele é: "você sabe o que fazer quando quebra? Está escrito em algum lugar, não na sua memória?" Até hoje a sua resposta era não, e não por descuido: ninguém documenta o que vem depois do "seu app está no ar 🎉". Agora está escrito.

É uma pergunta de dez. As outras da mesma fase, a de operar, são vizinhas desta noite: o backup que já voltou uma vez, o custo por mês, a pessoa de fora usando. Elas têm ordem, e a ordem existe pra que a próxima quebra te encontre sabendo onde tudo está, e não correndo de lá pra cá atrás de um programador.

Fontes