3:17 da manhã. O celular vibra. O monitor de uptime — um serviço que faz ping no seu site a cada poucos minutos e avisa quando ele para de responder — diz que seu app morreu. Sem equipe. Sem escala de plantão. Sem SRE (site reliability engineer, a pessoa cujo trabalho inteiro é manter serviços de pé). Só você, seu notebook e adrenalina.

Isso não é hipotético. Em 1º de março, a AWS sofreu uma falha em cascata que começou na região dos Emirados Árabes e se espalhou pela US-EAST-1, derrubando 38 serviços e deixando fundadores solo encarando dashboards de erro sem ninguém pra ligar. Depois, em 27 de março, o Cloudflare Pages quebrou o gerenciamento de domínios customizados por horas — ou seja, quem tinha deploy do site de marketing pelo Pages viu seus domínios sumirem da internet no meio do expediente.

Já estive nessa situação. Mais vezes do que uma capivara deveria admitir. Nas primeiras vezes, entrei em pânico e piorei tudo. Agora tenho um playbook. Ele tira o pânico da equação e substitui por passos. Aqui está ele completo. 📋

Passo 0: Não mexa em nada ainda

Contraintuitivo. Seu app está fora do ar. Cada segundo custa dinheiro, reputação, ou os dois. Seu instinto grita: conserta agora.

Mas a coisa mais perigosa que você pode fazer durante um incidente é agir sem entender o que quebrou.

Já vi fundadores solo darem SSH — conexão remota ao servidor via terminal seguro — na produção às 3 da manhã, rodarem um comando de memória e derrubarem o banco de dados junto com o app. Um problema virou dois. A correção original levaria 20 minutos. A recuperação do banco levou 6 horas.

Regra zero: antes de tocar em qualquer coisa, gaste 2 minutos entendendo a situação. Não 20 minutos. Dois. Leia o erro. Cheque os logs. Forme uma hipótese. Depois aja.

Passo 1: Triagem — 2 minutos

Faça três perguntas:

O serviço está completamente fora do ar ou parcialmente degradado? Acesse seu health endpoint — uma URL especial que reporta se os sistemas principais do seu app estão funcionando, como um check de batimento cardíaco embutido. Se o app carrega mas as chamadas de API (requisições do frontend pro backend) falham, é parcial. Se nada carrega, é total. Isso define a urgência.

Tem usuários sendo afetados agora? Cheque seu analytics. Se são 3 da manhã no seu fuso e seus usuários estão no mesmo fuso, talvez cinco pessoas perceberam. Se seus usuários são globais, centenas podem estar olhando pra uma página de erro agora mesmo.

Quando começou? Cheque seu dashboard de monitoramento. Se quebrou 5 minutos atrás, provavelmente está ligado à última coisa que mudou. Se o serviço está mancando há 3 horas e você só agora recebeu o alerta, seu monitoramento tem uma falha que você precisa corrigir amanhã.

Anote as respostas. Um caderno, uma mensagem pra você mesmo, um arquivo de texto. Isso se torna seu log de incidente — o documento único rastreando tudo sobre essa queda. Você vai se agradecer de manhã.

Passo 2: Comunique — 1 minuto

Mesmo que ninguém esteja acordado, publique uma atualização de status. Sua status page, suas redes sociais, seu Discord — onde seus usuários verificam. Uma frase:

"Estamos cientes de um problema afetando [serviço]. Investigando agora. Próxima atualização em 30 minutos."

Silêncio assusta mais que uma queda conhecida. Usuários que veem "investigando" esperam com paciência. Usuários que não veem nada assumem o pior e começam a postar sobre isso. Um minuto de comunicação compra 30 minutos de investigação tranquila. ⚙️

Passo 3: Cheque o óbvio — 5 minutos

80% dos incidentes em empresas pequenas se resumem a uma de cinco causas:

1. Disco cheio. Rode df -h (mostra espaço em disco em formato legível). Se algum filesystem marca 100%, achou o culpado. Correção rápida: encontrar e deletar arquivos de log gigantes. du -sh /var/log/* revela os responsáveis.

2. Sem memória. Rode free -h (mostra uso de RAM). Se a memória disponível está perto de zero, algo está acumulando. ps aux --sort=-%mem | head -10 lista os maiores consumidores de memória — o equivalente digital de descobrir quem deixou todas as luzes acesas. Mate o processo inchado, reinicie o serviço.

3. Processo morreu. Rode systemctl status seu-app — systemctl é o gerenciador de serviços do Linux, a ferramenta que inicia, para e monitora suas aplicações. Se diz "inactive (dead)" ou "failed", reinicie: systemctl restart seu-app. Depois cheque por que morreu: journalctl -u seu-app --since "1 hour ago" (journalctl lê o diário de eventos do sistema).

4. Certificado SSL expirou. SSL (Secure Sockets Layer) é o cadeado no seu navegador — significa que a conexão é criptografada. Esses certificados expiram. Certificados Let's Encrypt duram 90 dias. Se você esqueceu a renovação automática, esse é um problema de 3 da manhã esperando pra acontecer. Correção: certbot renew && systemctl reload nginx. Configure a renovação automática do Certbot neste fim de semana pra isso nunca mais acontecer.

5. Problema de DNS. DNS (Domain Name System) é a lista telefônica da internet — converte "seusite.com" em um endereço de servidor que computadores conseguem encontrar. Rode dig seusite.com pra checar. Se não resolve, seu provedor de DNS pode estar com problemas. Ou seu domínio expirou. Sim, domínios expiram. Já vi isso acontecer com startups que tinham investimento.

Se nenhuma dessas cinco bate, você está nos 20% que precisam de debug de verdade. Vá pro Passo 4.

Passo 4: Auditoria de mudanças recentes — 5 minutos

Algo mudou. Serviços não quebram espontaneamente — como encanamento, eles falham porque algo se mexeu. Pergunte:

  • Fiz deploy recentemente? Deploy significa enviar código novo pro seu servidor em produção. Cheque git log --since="24 hours ago" pra ver mudanças recentes no código.
  • Mudei alguma configuração? Cheque os timestamps de modificação dos seus arquivos de config.
  • Alguma dependência atualizou? Uma dependência é código de terceiros que seu app usa — uma biblioteca, um framework. Cheque seu lock file pra mudanças recentes.
  • O provedor de hospedagem teve algum problema? Cheque a status page deles.

A resposta mais comum: você fez deploy de algo. A correção: rollback — reverter pra versão anterior que funcionava. Não debugar. Rollback. Coloque o serviço de pé, debugue amanhã.

# Se você usa tags nos releases (labels de versão como v1.2.3):
git checkout v1.2.3
bash deploy.sh

# Se você ainda não usa tags (comece hoje):
git revert HEAD
bash deploy.sh

Fazer rollback parece desistir. Não é. É a resposta mais profissional que você pode dar: priorizar uptime em vez de ego. Corrija o código amanhã com café e luz do dia. 🍵

Passo 5: A regra dos 30 minutos

Se você não encontrou a causa raiz — o motivo real subjacente pelo qual algo quebrou, não só o sintoma — em 30 minutos, escale. "Mas eu sou fundador solo. Escalar pra quem?"

  • O suporte do seu provedor de hospedagem. Se você paga por hospedagem gerenciada, use. É literalmente pra isso que serve.
  • Um freelancer de plantão. Mesmo R$ 1.000/mês por "posso te mandar mensagem às 3 da manhã duas vezes por ano" já vale a pena.
  • Sua comunidade. Um servidor de Discord relevante, grupo no Slack ou fórum. Poste o erro, seus logs, o que você já tentou. Boas comunidades respondem rápido.
  • Um assistente de IA. Cole o erro no Claude ou ChatGPT: "Aqui está meu log de erro do servidor. O serviço caiu às 3:17. Aqui está o que eu já verifiquei: [lista]. O que mais eu deveria olhar?" Ele não vai dar SSH no seu servidor, mas pode sugerir passos de diagnóstico que você perdeu.

A regra dos 30 minutos existe porque depois de meia hora debugando sozinho às 3 da manhã, seu julgamento se deteriora. Você começa a tentar coisas aleatórias. Mudanças aleatórias num servidor de produção às 3 da manhã — é assim que dados desaparecem permanentemente.

Passo 6: A manhã pós-incidente

Você sobreviveu à crise. Volte a dormir. Sério. O postmortem — a análise estruturada do que deu errado e como prevenir — acontece amanhã. Com café. Com a cabeça limpa. 🛁

Checklist de amanhã:

  1. O que quebrou? Uma frase.
  2. Qual foi a causa raiz? Não "o servidor caiu" mas "Rotação de logs mal configurada encheu o disco a 100%."
  3. Qual foi o impacto? Duração, usuários afetados, receita perdida se mensurável.
  4. O que impediu detecção mais rápida? Corrija essa falha no monitoramento.
  5. O que impediu recuperação mais rápida? Adicione esse passo ao seu playbook.
  6. O que previne isso de acontecer de novo? Implemente esta semana. Não "um dia". Esta semana.

Escreva isso num arquivo. incidents/2026-03-27.md. Você está construindo conhecimento institucional — um histórico pesquisável do que quebrou antes e o que resolveu. Quando o próximo incidente acontecer, o você-do-passado já deixou anotações.

O setup pré-incidente

A melhor resposta a incidentes acontece antes do incidente. Aqui está o que configurar neste fim de semana:

  • Monitoramento de uptime. O UptimeRobot tem plano gratuito: 50 monitores, intervalos de 5 minutos. Ele faz ping no seu site e manda mensagem quando cai. Configure uma vez, esqueça. ✅
  • Rotação de logs. Configure o logrotate — utilitário Linux que automaticamente comprime e deleta logs antigos — pra cada log que seu app produz. Discos não enchem quando logs são gerenciados.
  • Renovação automática de SSL. Certbot com cron job (tarefa agendada que roda automaticamente num timer). Nunca mais renove um certificado manualmente.
  • Backups automatizados. Dump do banco pra S3 (armazenamento cloud da Amazon) ou qualquer object storage, a cada 6 horas. Teste o processo de restore pelo menos uma vez. Um backup que você nunca restaurou é uma esperança, não um backup.
  • Um script de rollback. Um comando pra reverter pra versão anterior. Zero pensamento necessário às 3 da manhã.

Setup total: aproximadamente 3 horas numa tarde tranquila de sábado. Essas 3 horas protegem seu negócio na próxima vez que algo quebrar no escuro.

Os fundadores mais tranquilos que conheço não são tranquilos porque nada quebra. Coisas quebram pra todo mundo. Eles são tranquilos porque têm um playbook. Já passaram por isso antes. Sabem o que fazer em seguida. E sabem — profundamente, por experiência — que entrar em pânico nunca, nenhuma vez, consertou um servidor. 🫶

incident-response, devops, automation, solo-founder, infrastructure